Re: New standby_slot_names GUC in PG 17 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: New standby_slot_names GUC in PG 17
Date
Msg-id CAA4eK1Lt8=e+m1QnBJKqSXjy_+AP3cU-=S4+oORgVT8J4Zx9+g@mail.gmail.com
Whole thread Raw
In response to Re: New standby_slot_names GUC in PG 17  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Sat, Jun 22, 2024 at 1:49 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> >>>>> Allow specification of physical standbys that must be synchronized
> >>>>> before they are visible to subscribers (Hou Zhijie, Shveta Malik)
> >
> > it seems like the name ought to have some connection to
> > synchronization.  Perhaps something like "synchronized_standby_slots"?
>
> IMHO that might be a bit too close to synchronous_standby_names.  But the
> name might not be the only issue, as there is a separate proposal [0] to
> add _another_ GUC to tie standby_slot_names to synchronous replication.  I
> wonder if this could just be a Boolean parameter or if folks really have
> use-cases for both a list of synchronous standbys and a separate list of
> synchronous standbys for failover slots.
>

Both have separate functionalities. We need to wait for the standby's
in synchronous_standby_names to be synced at the commit time whereas
the standby's in the standby_slot_names doesn't have such a
requirement. The standby's in the standby_slot_names are used by
logical WAL senders such that they will send decoded changes to
plugins only after the specified replication slots confirm receiving
WAL. So, combining them doesn't sound advisable.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: recoveryCheck/008_fsm_truncation is failing on dodo in v14- (due to slow fsync?)
Next
From: jian he
Date:
Subject: Re: SQL/JSON query functions context_item doc entry and type requirement