BF member skink (uses valgrind) has failed
subscription/t/036_sequences.pl twice since f38afa4ab went in.
I can reproduce that locally if I run the postmaster under valgrind.
However, valgrind isn't issuing any complaint AFAICT. It looks like
valgrind simply slows things down enough to expose a race condition.
What is in my subscriber's log is
...
2026-07-15 20:29:08.328 EDT client backend[3612746] 036_sequences.pl LOG: statement: ALTER SUBSCRIPTION
regress_seq_subREFRESH SEQUENCES
2026-07-15 20:29:09.083 EDT logical replication sequencesync worker[3612758] LOG: logical replication sequence
synchronizationworker for subscription "regress_seq_sub" has started
2026-07-15 20:29:10.095 EDT logical replication sequencesync worker[3612758] WARNING: insufficient privileges on
publishersequence ("public.regress_s2")
2026-07-15 20:29:10.095 EDT logical replication sequencesync worker[3612758] HINT: Grant SELECT on the sequence to the
roleused for the replication connection on the publisher.
2026-07-15 20:29:10.097 EDT logical replication sequencesync worker[3612758] ERROR: logical replication sequence
synchronizationfailed for subscription "regress_seq_sub"
2026-07-15 20:29:10.274 EDT postmaster[3612613] LOG: background worker "logical replication sequencesync worker" (PID
3612758)exited with exit code 1
2026-07-15 20:29:10.501 EDT logical replication sequencesync worker[3612763] LOG: logical replication sequence
synchronizationworker for subscription "regress_seq_sub" has started
2026-07-15 20:29:10.814 EDT client backend[3612766] 036_sequences.pl LOG: statement: ALTER SUBSCRIPTION
regress_seq_subREFRESH SEQUENCES
2026-07-15 20:29:10.837 EDT client backend[3612766] 036_sequences.pl ERROR: cannot execute ALTER SUBSCRIPTION ...
REFRESHSEQUENCES while a sequence synchronization worker is running
2026-07-15 20:29:10.837 EDT client backend[3612766] 036_sequences.pl HINT: Try again after the current synchronization
completes.
2026-07-15 20:29:10.837 EDT client backend[3612766] 036_sequences.pl STATEMENT: ALTER SUBSCRIPTION regress_seq_sub
REFRESHSEQUENCES
That is, after checking for the "insufficient privileges" case,
we aren't waiting long enough for the new seqsync worker to quiesce.
This wasn't a problem before f38afa4ab, because it wasn't an error
condition for that worker to still be running.
regards, tom lane
