Re: sequencesync worker race with REFRESH SEQUENCES

On Wed, Jul 22, 2026 at 8:58 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Wed, Jul 22, 2026 at 8:16 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > On Tue, 21 Jul 2026 at 12:49, shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > The logic of fix looks good. A few comments:
> > >
> > > 1)
> > > Note
> > > Sequence synchronization requires the publisher to be running
> > > PostgreSQL 19 or later.
> > >
> > > This note appears to be at odd position in
> > > logical-replication-sequences.html. Please have a look at html and
> > > move it to end of that section if you agree.
> >
> > Modified
> >
> > > 2)
> > > + from the tables themselves. Note that
> > > + <link linkend="sql-altersubscription-params-refresh-sequences">
> > > + <command>ALTER SUBSCRIPTION ... REFRESH SEQUENCES</command></link> only
> > > + re-synchronizes sequences that are already known to the subscription
> > > + (see <xref linkend="logical-replication-sequences"/>); in particular, it
> > > + requires the publisher to be running <productname>PostgreSQL</productname>
> > > + 19 or later. Before relying on it to prepare for a switchover or
> > > + failover, confirm that the publisher's version supports sequence
> > > + replication and that the sequences of interest are already known to the
> > > + subscription.
> > >
> > > Do you think above is necessary? At subscription creation time, a
> > > publisher running a version earlier than PostgreSQL 19 cannot have a
> > > publication containing all sequences, so the subscription cannot have
> > > such sequences known to it. Furthermore, ALTER SUBSCRIPTION to change
> > > publisher-connection will report an error if the required
> > > prerequisites are not met. Therefore, asking users to separately
> > > verify the publisher version and sequence membership seems redundant
> > > to me.
> >
> > This scenario can be possible, Kuroda-san has reported a similar issue at [1].
> >
> > > 3)
> > > +bool
> > > +HasSubscriptionSequences(Oid subid)
> > >
> > > Do you think we can resuse HasSubscriptionTables instead of
> > > duplicating the complete code? We can have
> > > HasSubscriptionRelations(subid, bool *has_tables, bool
> > > *has_sequences)) Or is it not worth?
> >
> > Since checking at set connection does not handle all the cases, now
> > I'm checking this at refresh sequences because of which this code has
> > been now removed.
> >
> > The attached patch has the changes for the same. This patch also fixes
> > the issue reported by Kuroda-san at [1].
> >
>
> When this idea was discussed earlier, I had asked whether we could
> move the version check from copy_sequences() to the apply worker
> (ProcessSequencesForSync) before it starts sequnece sync worker. The
> intention was to avoid repeatedly starting the sequence-sync worker
> only for it to exit in copy_sequences(). The apply worker itself could
> report an error similar to how the backend reports it during REFRESH.
> Thoughts?

Apply-worker can report a WARNING instead of ERROR. It's no use if the
apply worker keeps exiting and restarting instead of the seqsync
worker.

> --
>
> Commit msg says:
> Sequence synchronization relies on pg_get_sequence_data(), which was
> added in PostgreSQL 19.
>
> IIRC, it is present in PG18 as well, no?
>
> thanks
> Shveta