Re: Synchronizing slots from primary to standby

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. 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.

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?

thanks
Shveta