Horton

Re: Logical Replication of sequences

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: vignesh C <vignesh21@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, shveta malik <shveta.malik@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2025-10-27T06:41:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Doc: Add documentation for sequence synchronization.

  2. Remove unused assignment in CREATE PUBLICATION grammar.

  3. Add seq_sync_error_count to subscription statistics.

  4. Fix few issues in commit 5509055d69.

  5. Add sequence synchronization for logical replication.

  6. Add worker type argument to logical replication worker functions.

  7. Introduce "REFRESH SEQUENCES" for subscriptions.

  8. Refactor logical worker synchronization code into a separate file.

  9. Standardize use of REFRESH PUBLICATION in code and messages.

  10. Add "ALL SEQUENCES" support to publications.

  11. Expose sequence page LSN via pg_get_sequence_data.

  12. Resume conflict-relevant data retention automatically.

  13. Post-commit review fixes for 228c370868.

  14. Generate GUC tables from .dat file

On Mon, Oct 27, 2025 at 10:04 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Mon, Oct 27, 2025 at 8:23 AM Zhijie Hou (Fujitsu) <
> houzj.fnst@fujitsu.com> wrote:
>
>> On Friday, October 24, 2025 11:22 PM vignesh C <vignesh21@gmail.com>
>> wrote:
>> >
>> > On Thu, 23 Oct 2025 at 16:47, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> > >
>> > > On Thu, Oct 23, 2025 at 11:45 AM vignesh C <vignesh21@gmail.com>
>> wrote:
>> > > >
>> > > > The attached patch has the changes for the same.
>> > > >
>> > >
>> > > I have pushed 0001 and the following are comments on 0002.
>> >
>>
>
> One question, I am not sure if this has been discussed before, So while
> getting sequence information from remote we are also getting the page_lsn
> of the sequence and we are storing that in pg_subscription_rel.  Is it just
> for the user to see and compare whether the sequence is synced to the
> latest lsn or is it used for anything else as well?  In our patch sert, I
> don't see much usability information about this field.
>

Overall patch LGTM, and I really like the idea of getting rid of the hash
and converting it into a list, now we don't need to restart the scan unlike
hash due to transaction boundary.  However I have one more suggestion.

 /*
+ * Establish the connection to the publisher for sequence synchronization.
+ */
+ LogRepWorkerWalRcvConn =
+ walrcv_connect(MySubscription->conninfo, true, true,
+   must_use_password,
+   app_name.data, &err);
+ if (LogRepWorkerWalRcvConn == NULL)
+ ereport(ERROR,
+ errcode(ERRCODE_CONNECTION_FAILURE),
+ errmsg("sequencesync worker for subscription \"%s\" could not connect to
the publisher: %s",
+   MySubscription->name, err));
+
+ pfree(app_name.data);
+
+ /* If there are any sequences that need to be copied */
+ if (hash_get_num_entries(sequences_to_copy))
+ copy_sequences(LogRepWorkerWalRcvConn, subid);

I think we should call 'walrcv_connect' only if we need to copy_sequences
right?

-- 
Regards,
Dilip Kumar
Google