Re: Synchronizing slots from primary to standby
От | Bertrand Drouvot |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | ZZ+dmz/myfv2TGp8@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | RE: Synchronizing slots from primary to standby ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
Hi, On Wed, Jan 10, 2024 at 12:23:14PM +0000, Zhijie Hou (Fujitsu) wrote: > On Wednesday, January 10, 2024 2:26 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > + LogicalConfirmReceivedLocation(remote_slot->confirmed_lsn); > > + LogicalIncreaseXminForSlot(remote_slot->confirmed_lsn, > > + remote_slot->catalog_xmin); > > + LogicalIncreaseRestartDecodingForSlot(remote_slot->confirmed_lsn, > > + remote_slot->restart_lsn); > > +} > > > > IIUC on the standby we just want to overwrite what we get from primary no? If > > so why we are using those APIs that are meant for the actual decoding slots > > where it needs to take certain logical decisions instead of mere overwriting? > > I think we don't have a strong reason to use these APIs, but it was convenient to > use these APIs as they can take care of updating the slots info and will call > functions like, ReplicationSlotsComputeRequiredXmin, > ReplicationSlotsComputeRequiredLSN internally. Or do you prefer directly overwriting > the fields and call these manually ? I'd vote for using the APIs as I think it will be harder to maintain if we are not using them (means ensure the "direct" overwriting still makes sense over time). FWIW, pg_failover_slots also rely on those APIs from what I can see. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: