Re: sequencesync worker race with REFRESH SEQUENCES

On Fri, 10 Jul 2026 at 10:22, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> A Fable 5 review of logical replication of sequences found a way to get
> subscribed sequences into READY state despite the subscriber side having data
> older than the last REFRESH SEQUENCES. I'm attaching the test case it wrote.
> I reviewed the test, and I think it identifies a genuine defect.

Thanks for reporting this. The test case reproduces this issue. This
issue is not limited to lock contention. It can also occur if the
sequence synchronization worker is simply slow. For example, the
worker may fetch the sequence value from the publisher, after which
the publisher sequence advances and ALTER SUBSCRIPTION ... REFRESH
SEQUENCES is executed. When the worker eventually updates the
subscriber, it uses the stale value that it fetched earlier,
overwriting the sequence with an out-of-date value.

How about raising a warning for the second REFRESH SEQUENCES
indicating that the sequence is already being synchronized and
skipping it? The warning could also include a hint to rerun ALTER
SUBSCRIPTION ... REFRESH SEQUENCES after the current synchronization
completes. This approach avoids making ALTER SUBSCRIPTION ... REFRESH
SEQUENCES wait for the sequence synchronization worker, which could
itself be blocked waiting for a lock held by a long-running
transaction on the sequence.

Regards,
Vignesh