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

On Wed, Nov 29, 2023 at 3:24 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> On 11/29/23 6:58 AM, Zhijie Hou (Fujitsu) wrote:
> > On Tuesday, November 28, 2023 8:07 PM Drouvot, Bertrand <bertranddrouvot.pg@gmail.com> wrote:
> >
> > Hi,
> >
> >> On 11/27/23 9:57 AM, Zhijie Hou (Fujitsu) wrote:
> >>> On Monday, November 27, 2023 4:51 PM shveta malik
> >> <shveta.malik@gmail.com> wrote:
> >>>
> >>> Here is the updated version(v39_2) which include all the changes made in
> >> 0002.
> >>> Please use for review, and sorry for the confusion.
> >>>
> >>
> >> Thanks!
> >>
> >> As far v39_2-0001:
> >>
> >> "
> >>       Altering the failover option of the subscription is currently not
> >>       permitted. However, this restriction may be lifted in future versions.
> >> "
> >>
> >> Should we mention that we can alter the related replication slot?
> >
> > Will add.
> >
> >>
> >> +         <para>
> >> +          The implementation of failover requires that replication
> >> +          has successfully finished the initial table synchronization
> >> +          phase. So even when <literal>failover</literal> is enabled for a
> >> +          subscription, the internal failover state remains
> >> +          temporarily <quote>pending</quote> until the initialization
> >> phase
> >> +          completes. See column
> >> <structfield>subfailoverstate</structfield>
> >> +          of <link
> >> linkend="catalog-pg-subscription"><structname>pg_subscription</structna
> >> me></link>
> >> +          to know the actual failover state.
> >> +         </para>
> >>
> >> I think we have a corner case here. If one alter the replication slot on the
> >> primary then "subfailoverstate" is not updated accordingly on the subscriber.
> >> Given the 2 remarks above would that make sense to prevent altering a
> >> replication slot associated to a subscription?
> >
> > Thanks for the review!
> >
> > I think we could not distinguish the user created logical slot or subscriber
> > created slot as there is no related info in slot's data.
>
> Yeah that would need extra work.
>
> > And user could change
> > the slot on subscription by "alter sub set (slot_name)", so maintaining this info
> > would need some efforts.
> >
>
> Yes.
>
> > Besides, I think this case overlaps the previous discussed "alter sub set
> > (slot_name)" issue[1]. Both the cases are because the slot's failover is
> > different from the subscription's failover setting.
>
> Yeah agree.
>
> > I think we could handle
> > them similarly that user need to take care of not changing the failover to
> > wrong value. Or do you prefer another approach that mentioned in that thread[1]
> > ? (always alter the slot at the startup of apply worker).
> >
>
> I think I'm fine with documenting the fact that the user should not change the failover
> value. But if he does change it (because at the end nothing prevents it to do so) then
> I think the meaning of subfailoverstate should still make sense.
>

How user can change the slot's failover property? Do we provide any
command for it?

--
With Regards,
Amit Kapila.