Hi, On 10/4/23 7:00 AM, shveta malik wrote:
On Wed, Oct 4, 2023 at 9:56 AM shveta malik <shveta.ma...@gmail.com> wrote:
The most simplistic approach would be: 1) maintain standby_slot_names GUC on primary 2) maintain synchronize_slot_names GUC on physical standby alone. On primary, let all logical-walsenders wait on physical-standbys configured in standby_slot_names GUC. This will work and will avoid all the complexity involved in designs discussed above. But this simplistic approach comes with disadvantages like below: 1) Even if the associated slot of logical-walsender is not part of synchronize_slot_names of any of the physical-standbys, it is still waiting for all the configured standbys to finish.
That's right. Currently (with walsender waiting an arbitrary amount of time) that sounds like a -1. But if we're going with a new CV approach (like proposed in [1], that might not be so terrible). Though I don't feel comfortable with waiting for no reasons (even if this is for a short amount of time possible).
2) If associated slot of logical walsender is part of synchronize_slot_names of standby1, it is still waiting on standby2,3 etc to finish i.e. waiting on rest of the standbys configured in standby_slot_names which have not even marked that logical slot in their synchronize_slot_names.
Same thoughts as above for 1)
So we need to weigh our options here.
With the simplistic approach, if a standby goes down that would impact non related walsenders on the primary until the standby's associated physical slot is removed from standby_slot_names and I don't feel comfortable wit this behavior. So, I'm +1 for the ReplicationSlotPersistentData approach proposed by Amit. [1]: https://www.postgresql.org/message-id/CAA4eK1LNjgL6Lghgu1PcDfuoOfa8Ug4J7Uv-H%3DBPP8Wgf1%2BpOw%40mail.gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
