On Wed, Nov 29, 2023 at 3:24 PM Drouvot, Bertrand <bertranddrouvot...@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...@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.ma...@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.
