| 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].
Regards,
Vignesh
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Reject-sequence-synchronization-against-pre-PG19-.patch | application/octet-stream | 5.3 KB |
| 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 |