Re: sequencesync worker race with REFRESH SEQUENCES

On Sat, Jul 18, 2026 at 8:10 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Sat, 18 Jul 2026 at 09:05, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > I have pushed the revert. Attached patch fixes the race without taking
> > lock on pg_subscription_rel.
>
> The changes look good to me. I verified the behavior using a debugger
> on both the PG20 and PG19 branches, confirming that a concurrent
> refresh successfully stops the sequence sync worker and resets the
> sequences to their initial state. I also verified the fix using the
> attached injection point test. I'm not entirely sure if we should
> include this test in the final commit, as it requires introducing a
> new injection point to the codebase.
>

Thanks for the test, it helps in verifying functionality. However, it
fails intermittently on my Windows environment. IIUC, the stop of
worker being performed by REFRESH doesn't honor injection_point wait.
So, it is not able to coordinate the REFRESH and wait which leads to
this failure. See:

[09:09:58.126](3.805s) ok 10 - sequence is still in INIT state while
the worker is blocked
[09:09:58.453](0.328s) ok 11 - sequence remains in INIT state after
the second REFRESH SEQUENCES stops the worker
[09:15:40.610](342.157s) # poll_query_until timed out executing this query:
# SELECT count(1) = 0 FROM pg_subscription_rel WHERE srsubstate NOT IN ('r');
# expecting this output:
# t
# last actual query output:
# f
# with stderr:
[09:15:40.612](0.002s) # die: Timed out while waiting for subscriber
to synchronize data at
C:/Workspace/code/postgresql/src/test/subscription/t/036_sequences.pl
line 311.

I am attaching the subscriber log as well. I am planning to proceed
without a test as I also can't see a reliable way to write an
automated test for it. But if you can come up with something, we can
add it as well.

--
With Regards,
Amit Kapila.