Re: sequencesync worker race with REFRESH SEQUENCES

From: vignesh C <vignesh21(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Date: 2026-07-22 02:46:31
Message-ID: CALDaNm3RPwc3uHK3OV0qM41YvO7qHkx6yAu4ayScTo7kaMZ_AQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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].

[1] - https://www.postgresql.org/message-id/flat/OS9PR01MB12149C5AC91BB56D5CB4B96B2F5C22%40OS9PR01MB12149.jpnprd01.prod.outlook.com#a291e836a2bb2736ca36c8d127e2dc77

Regards,
Vignesh

Attachment Content-Type Size
v5-0001-Reject-sequence-synchronization-against-pre-PG19-.patch application/octet-stream 5.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-07-22 02:50:28 Re: Make the logical replication conflict messages more like each other
Previous Message Peter Smith 2026-07-22 02:35:55 Re: Logical Replication - revisit `is_table_publication` function implementation