Re: sequencesync worker race with REFRESH SEQUENCES

On Fri, Jul 31, 2026 at 02:55:33PM +0530, Amit Kapila wrote:
> On Fri, Jul 31, 2026 at 11:06 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > 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.
>
> I agree with your analysis of the reported issues and will close the
> corresponding open item [1] early next week unless someone thinks
> otherwise. Noah, would you like to cross-verify?

No need to involve me at that level of detail. Thanks. I'm glad some of the
lesser findings also deserved changes.