Re: Logical Replication of sequences
| От | vignesh C |
|---|---|
| Тема | Re: Logical Replication of sequences |
| Дата | |
| Msg-id | CALDaNm3Bfwo-Rv-xXYBfdVnDNSqWsMk+pw7U7b6fz=Shm86PHw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Logical Replication of sequences (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: