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]. [1] - https://www.postgresql.org/message-id/flat/OS9PR01MB12149C5AC91BB56D5CB4B96B2F5C22%40OS9PR01MB12149.jpnprd01.prod.outlook.com#a291e836a2bb2736ca36c8d127e2dc77 Regards, Vignesh
v5-0001-Reject-sequence-synchronization-against-pre-PG19-.patch
Description: Binary data
