Re: sequencesync worker race with REFRESH SEQUENCES

On Fri, 10 Jul 2026 at 10:22, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
The other findings are gray areas, perhaps.

I had analyzed some more issues and found that these issues need to be fixed:
a) Finding 9: A running sequence synchronization worker continues
processing after ALTER SUBSCRIPTION ... DISABLE. In this case the
leader apply worker only terminated its parallel apply workers on
detach, so a running sequencesync worker could outlive a DISABLE.
logicalrep_worker_detach() now also stops the sequencesync worker. b)
Finding 11: The sequence-removal loop runs after publisher-side
synchronization slots are dropped, violating the existing "slot drops
last" invariant. The fix moves the sequence-removal loop before the
slot-drop loop to keep the drop slots at the end. c) Finding 14: psql
tab completion for ALTER SUBSCRIPTION ... REFRESH PUBLICATION
regressed and no longer suggests WITH (. The fix restores the missing
tab-completion rule. d) Finding 15: pg_stat_subscription reports
misleading timestamp values for the sequence synchronization worker,
and the documentation does not describe its NULL column values. The
fix reports NULL for the appropriate timestamp fields and updates the
monitoring documentation accordingly. e) Finding 16: The catalogs.sgml
description of srsublsn does not describe its meaning for sequence
rows. The fix updates the documentation to describe the semantics of
srsublsn for sequence rows.

There are a few remaining issues that I will discuss in a subsequent email.

Regards,
Vignesh