Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id CAA4eK1JcBG6TJ3o5iUd4z0BuTbciLV3dK4aKgb7OgrNGoLcfSQ@mail.gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Synchronizing slots from primary to standby
List pgsql-hackers
On Tue, Oct 17, 2023 at 9:06 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> On 10/13/23 10:35 AM, shveta malik wrote:
> > On Thu, Oct 12, 2023 at 9:18 AM shveta malik <shveta.malik@gmail.com> wrote:
> >>
>
> Code:
>
> +       True if this logical slot is enabled to be synced to the physical standbys
> +       so that logical replication is not blocked after failover. Always false
> +       for physical slots.
>
> Not sure "not blocked" is the right wording. "can be resumed from the new primary" maybe?
>

Yeah, your proposed wording sounds better. Also, I think we should
document the impact of not doing so because I think the replication
can continue after failover but it may lead to data inconsistency.

BTW, I noticed that the code for Create Subscription is updated but
not the corresponding docs. By looking at other parameters like
password_required, streaming, two_phase where true or false indicates
whether that option is enabled or not, I am thinking about whether
enable_failover is an appropriate name for this option. The other
option name that comes to mind is 'failover' where true indicates that
the corresponding subscription will be enabled for failover. What do
you think?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Andrei Lepikhov
Date:
Subject: Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs