Re: Synchronizing slots from primary to standby

Hi,

On 11/8/23 12:50 PM, shveta malik wrote:
> On Wed, Nov 8, 2023 at 3:19 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>> Hi,
>>
>> On 11/8/23 9:57 AM, Amit Kapila wrote:
>>> On Wed, Nov 8, 2023 at 12:32 PM Drouvot, Bertrand
>>> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 11/8/23 4:50 AM, Amit Kapila wrote:
>>>>
>>>>> I think if we want to follow
>>>>> this approach then we need to also monitor these slots for any change
>>>>> in the consecutive cycles and if we are able to sync them then
>>>>> accordingly we enable them to use after failover.
>>>>
>>>> What about to add a new field in ReplicationSlotPersistentData
>>>> indicating that we are waiting for "sync" and drop such slots during promotion and
>>>> /or if not in recovery?
>>>>
>>>
>>> This patch is already adding 'synced' flag in
>>> ReplicationSlotPersistentData to distinguish synced slots so that we
>>> can disallow decoding on then in standby and disallow to drop those. I
>>> suggest we change that field to have multiple states where one of the
>>> states would indicate that the initial sync of the slot is done.
>>>
>>
>> Yeah, agree.
>>
>
> I am working on this implementation.

Thanks!

> This sync-state is even needed
> for cascading standbys to know when to start syncing the slots from
> the first standby. It should start syncing only after the first
> standby has finished initialization of it (i.e. wait for primary is
> over) and not before that.
>

Yeah, makes sense.

> Unrelated to above, if there is a user slot on standby with the same
> name which the slot-sync worker is trying to create, then shall it
> emit a warning and skip the sync of that slot or shall it throw an
> error?
>

I'd vote for emit a warning and move on to the next slot if any.

Regards,

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