Horton

Re: Logical Replication of sequences

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2025-10-06T06:19:52Z
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 Sun, 5 Oct 2025 at 07:54, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sat, Oct 04, 2025 at 09:24:32PM +0530, Amit Kapila wrote:
> > In the 0001 patch, pg_get_sequence_data() exposes two new fields
> > log_cnt and page_lsn. I see that the later subscriber-side patch uses
> > both, the first one in SetSequence(). It is not clear from the
> > comments or the commit message of 0001 why it is necessary to use
> > log_cnt when setting the sequence. Can you explain what the problem
> > will be if we don't use log_cnt during sequence sync?
>
> FWIW, I have argued two times at least that it should never be
> necessary to expose log_cnt in the sequence meta-data: this is just a
> counter to decide when a WAL record of a sequence should be generated.

Thanks, I have verified that the log_cnt value is not retained after an upgrade:
create sequence s1;
select nextval('s1');
select nextval('s1');

postgres=# select * from s1;
last_value | log_cnt | is_called
------------+---------+-----------
          2 |      31 | t
(1 row)

After upgrade:
postgres=# select * from s1;
last_value | log_cnt | is_called
------------+---------+-----------
          2 |       0 | t
(1 row)

Since the log_cnt value is not preserved across upgrades, copying it
would have no effect. I’ll remove log_cnt from pg_get_sequence_data
and post an updated version of the patch.

Regards,
Vignesh