Re: Synchronizing slots from primary to standby

Hi,

On 10/3/23 12:54 PM, Amit Kapila wrote:
> On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>> On 9/29/23 1:33 PM, Amit Kapila wrote:
>>> On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand
>>> <bertranddrouvot(dot)pg(at)gmail(dot)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