Re: Synchronizing slots from primary to standby
От | Drouvot, Bertrand |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | 32e27060-fdb0-472a-ab58-2f9ee010f161@gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
(shveta malik <shveta.malik@gmail.com>)
|
Список | pgsql-hackers |
Hi, On 10/3/23 12:54 PM, Amit Kapila wrote: > On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand > <bertranddrouvot.pg@gmail.com> wrote: >> >> On 9/29/23 1:33 PM, Amit Kapila wrote: >>> On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand >>> <bertranddrouvot.pg@gmail.com> wrote: >>>> >>> >>>> - probably open corner cases like: what if a standby is down? would that mean >>>> that synchronize_slot_names not being send to the primary would allow the decoding >>>> on the primary to go ahead? >>>> >>> >>> Good question. BTW, irrespective of whether we have >>> 'standby_slot_names' parameters or not, how should we behave if >>> standby is down? Say, if 'synchronize_slot_names' is only specified on >>> standby then in such a situation primary won't be even aware that some >>> of the logical walsenders need to wait. >> >> Exactly, that's why I was thinking keeping standby_slot_names to address >> this scenario. In such a case one could simply decide to keep or remove >> the associated physical replication slot from standby_slot_names. Keep would >> mean "wait" and removing would mean allow to decode on the primary. >> >>> OTOH, one can say that users >>> should configure 'synchronize_slot_names' on both primary and standby >>> but note that this value could be different for different standby's, >>> so we can't configure it on primary. >>> >> >> Yeah, I think that's a good use case for standby_slot_names, what do you think? >> > > But, even if we keep 'standby_slot_names' for this purpose, the > primary doesn't know the value of 'synchronize_slot_names' once the > standby is down and or the primary is restarted. So, how will we know > which logical WAL senders needs to wait for 'standby_slot_names'? > Yeah right, I also think we'd need: - synchronize_slot_names on both primary and standby But now we would need to take care of different standby having different values ( as you said up-thread).... Thinking out loud: What about a single GUC on the primary (not standby_slot_names nor synchronize_slot_names) but say logical_slots_wait_for_standby that could be a list of say "logical_slot_name:physical_slot". I think this GUC would help us define each walsender behavior (should the standby(s) be up or down): - don't wait if its associated logical_slot is not listed in this GUC - or wait based on its associated "list" of mapped physical slots (would probably have to deal with the min restart_lsn for all the corresponding mapped ones). I don't think we can avoid having to define at least one GUC on the primary (at least to handle the case of standby(s) being down). Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: