Hi,
On 11/8/23 12:50 PM, shveta malik wrote:
On Wed, Nov 8, 2023 at 3:19 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.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...@gmail.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
