On Mon, Nov 20, 2023 at 3:17 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 11/18/23 11:45 AM, Amit Kapila wrote: > > On Fri, Nov 17, 2023 at 5:18 PM Drouvot, Bertrand > > <bertranddrouvot...@gmail.com> wrote: > >> > >> On 11/17/23 2:46 AM, Zhijie Hou (Fujitsu) wrote: > >>> On Tuesday, November 14, 2023 10:27 PM Drouvot, Bertrand > >>> <bertranddrouvot...@gmail.com> wrote: > >>> > >>> I feel the WaitForWALToBecomeAvailable may not be the best place to > >>> shutdown > >>> slotsync worker and drop slots. There could be other reasons(other than > >>> promotion) as mentioned in comments in case XLOG_FROM_STREAM to reach the > >>> code > >>> there. I thought if the intention is to stop slotsync workers on > >>> promotion, > >>> maybe FinishWalRecovery() is a better place to do it as it's indicating > >>> the end > >>> of recovery and XLogShutdownWalRcv is also called in it. > >> > >> I can see that slotsync_drop_initiated_slots() has been moved in > >> FinishWalRecovery() > >> in v35. That looks ok. > >>> > > > > I was thinking what if we just ignore creating such slots (which > > require init state) in the first place? I think that can be > > time-consuming in some cases but it will reduce the complexity and we > > can always improve such cases later if we really encounter them in the > > real world. I am not very sure that added complexity is worth > > addressing this particular case, so I would like to know your and > > others' opinions. > > > > I'm not sure I understand your point. Are you saying that we should not create > slots on the standby that are "currently" reported in a 'i' state? (so just > keep > the 'r' and 'n' states?) >
Yes. -- With Regards, Amit Kapila.
