Re: Synchronizing slots from primary to standby

Hi,

On 10/4/23 1:50 PM, shveta malik wrote:
> On Wed, Oct 4, 2023 at 5:00 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand
>> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>>
>>> On 10/4/23 6:26 AM, shveta malik wrote:
>>>> On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>>>>
>>>>>
>>>>> How about an alternate scheme where we define sync_slot_names on
>>>>> standby but then store the physical_slot_name in the corresponding
>>>>> logical slot (ReplicationSlotPersistentData) to be synced? So, the
>>>>> standby will send the list of 'sync_slot_names' and the primary will
>>>>> add the physical standby's slot_name in each of the corresponding
>>>>> sync_slot. Now, if we do this then even after restart, we should be
>>>>> able to know for which physical slot each logical slot needs to wait.
>>>>> We can even provide an SQL API to reset the value of
>>>>> standby_slot_names in logical slots as a way to unblock decoding in
>>>>> case of emergency (for example, corresponding when physical standby
>>>>> never comes up).
>>>>>
>>>>
>>>>
>>>> Looks like a better approach to me. It solves most of the pain points like:
>>>> 1) Avoids the need of multiple GUCs
>>>> 2) Primary and standby need not to worry to be in sync if we maintain
>>>> sync-slot-names GUC on both
>>
>> As per my understanding of this approach, we don't want
>> 'sync-slot-names' to be set on the primary. Do you have a different
>> understanding?
>>
>
> Same understanding. We do not need it to be set on primary by user. It
> will be GUC on standby and standby will convey it to primary.

+1, same understanding here.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com