Hi,
On 10/3/23 12:54 PM, Amit Kapila wrote:
On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand
<bertranddrouvot...@gmail.com> wrote:
On 9/29/23 1:33 PM, Amit Kapila wrote:
On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.com> wrote:
- probably open corner cases like: what if a standby is down? would that mean
that synchronize_slot_names not being send to the primary would allow the
decoding
on the primary to go ahead?
Good question. BTW, irrespective of whether we have
'standby_slot_names' parameters or not, how should we behave if
standby is down? Say, if 'synchronize_slot_names' is only specified on
standby then in such a situation primary won't be even aware that some
of the logical walsenders need to wait.
Exactly, that's why I was thinking keeping standby_slot_names to address
this scenario. In such a case one could simply decide to keep or remove
the associated physical replication slot from standby_slot_names. Keep would
mean "wait" and removing would mean allow to decode on the primary.
OTOH, one can say that users
should configure 'synchronize_slot_names' on both primary and standby
but note that this value could be different for different standby's,
so we can't configure it on primary.
Yeah, I think that's a good use case for standby_slot_names, what do you think?
But, even if we keep 'standby_slot_names' for this purpose, the
primary doesn't know the value of 'synchronize_slot_names' once the
standby is down and or the primary is restarted. So, how will we know
which logical WAL senders needs to wait for 'standby_slot_names'?
Yeah right, I also think we'd need:
- synchronize_slot_names on both primary and standby
But now we would need to take care of different standby having different values
(
as you said up-thread)....
Thinking out loud: What about a single GUC on the primary (not
standby_slot_names nor
synchronize_slot_names) but say logical_slots_wait_for_standby that could be a
list of say
"logical_slot_name:physical_slot".
I think this GUC would help us define each walsender behavior (should the
standby(s)
be up or down):
- don't wait if its associated logical_slot is not listed in this GUC
- or wait based on its associated "list" of mapped physical slots (would
probably
have to deal with the min restart_lsn for all the corresponding mapped ones).
I don't think we can avoid having to define at least one GUC on the primary (at
least to
handle the case of standby(s) being down).
Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
