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.
>
> Fable 5 also wrote a lot more that neither it nor I confirmed by test case
> construction. I'm attaching the report; feel free to disregard.

Here's the summary of the findings:
Finding 1: Refresh paths race the in-flight sequencesync worker -
committed (45cf7b1e5bf923ca48dfd9aa5001bdd0630d11c3)
Finding 2: `default_transaction_read_only=on` permanently blocks
sequence sync - committed (4cd02d552263ed8d4b148aaefd24cd9dd8af57ed)
Finding 3: `run_as_owner=false`: one un-SET-ROLE-able sequence owner
stalls all sequence sync, unattributed - Rejected at [1]
Finding 4: Gathering scan holds a lock on every INIT relation in one
unbounded transaction - committed
(c12c101b0846b1e6488f2dc986a852fbc6bf2e3b)
Finding 5: Sequencesync worker starved by tablesync workers; REFRESH
SEQUENCES silently deferred - Rejected at [1]
Finding 6: No publisher-version guard: pre-PG19 publisher causes a
perpetual, cryptic error loop - committed
(57e7c52c0fe43fff36d0f4440eea13cf5668b160)
Finding 7: `has_sequence_privilege()` NULL on concurrent publisher
DROP: Assert crash / wrong diagnosis - committed
(55f518684895bfe43e667acf59284b49707ee685)
Finding 8: Permission-denied sequences double-reported as "missing on
publisher" - committed (13b7a8a0ef56d9decae284b4983894175c17d217)
Finding 9: ALTER SUBSCRIPTION ... DISABLE never stops a running
sequencesync worker - committed
(b8d9cf512c1259f97f9896593cc1c8352c1118ac)
Finding 10: REFRESH SEQUENCES vs concurrent subscriber DROP SEQUENCE:
internal XX000 errors - Rejected at [1]
Finding 11: Sequence-removal loop runs after irreversible tablesync
slot drops - committed (b8d9cf512c1259f97f9896593cc1c8352c1118ac)
Finding 12: Batch query mixes MVCC definition columns with live
`last_value`: validation bypass - this is a base code issue, which is.
being tracked at [2]
Finding 13: REFRESH SEQUENCES warning misattributes a `copy_data`
request the command cannot express - committed
(00b3e50054dad648e74d19cc199555381ab366d2)
Finding 14: psql tab-completion regression after `REFRESH PUBLICATION`
- committed (b8d9cf512c1259f97f9896593cc1c8352c1118ac)
Finding 15: pg_stat_subscription row for the sequencesync worker:
fabricated times, undocumented NULLs - committed
(b8d9cf512c1259f97f9896593cc1c8352c1118ac)
Finding 16: catalogs.sgml `srsublsn` description wrong for sequence
rows - committed (b8d9cf512c1259f97f9896593cc1c8352c1118ac)
Finding 17: Docs omit the PG19+ publisher requirement for sequence
sync; REFRESH SEQUENCES silently no-ops - committed
(57e7c52c0fe43fff36d0f4440eea13cf5668b160)
Finding 18: Restrictions bullet still claims only tables can be
replicated - Rejected at [1]

With all agreed issues now committed, the remaining four findings
rejected by consensus, and Finding 12 being tracked separately as a
pre-existing base code issue, I believe all items have been addressed.
I felt this thread can now be marked as closed.

[1] - https://www.postgresql.org/message-id/CALDaNm30Cr9n9YLHLnVDMbmUT%3DsegVQF2p0J3NMhUjrE1Mm9cw%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CALDaNm3s1EmdEd%2BRO%2BTt8aWadZedxwZmE0hTiNSmO6ks4vdhSg%40mail.gmail.com

Regards,
Vignesh