On Wed, Jul 22, 2026 at 8:58 AM shveta malik <[email protected]> wrote: > > On Wed, Jul 22, 2026 at 8:16 AM vignesh C <[email protected]> wrote: > > > > On Tue, 21 Jul 2026 at 12:49, shveta malik <[email protected]> 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
