At Tue, 13 Sep 2022 11:56:16 +0530, Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote in > On Tue, Sep 13, 2022 at 8:52 AM Noah Misch <n...@leadboat.com> wrote: > > > > > > > [1] - > > > > > https://www.postgresql.org/message-id/flat/20220909.172949.2223165886970819060.horikyota.ntt%40gmail.com > > > > I plan to use that message's patch, because it guarantees WALRCV_STOPPED at > > the code location being changed. Today, in the unlikely event of > > !WalRcvStreaming() due to WALRCV_WAITING or WALRCV_STOPPING, that code > > proceeds without waiting for WALRCV_STOPPED. > > Hm. That was the original fix [2] proposed and it works. The concern
(Mmm. sorry for omitting that.) > is that XLogShutdownWalRcv() does a bunch of work via ShutdownWalRcv() > - it calls ConditionVariablePrepareToSleep(), Anyway the code path is executed in almost all cases because the same assertion fires otherwise. So I don't see a problem if we do the bunch of synchronization things also in that rare case. I'm not sure we want to do [3]. > > If WALRCV_WAITING or WALRCV_STOPPING can happen at that patch's code site, I > > perhaps should back-patch the change to released versions. Does anyone know > > whether one or both can happen? > > IMO, we must back-patch to the version where > cc2c7d65fc27e877c9f407587b0b92d46cd6dd16 got introduced irrespective > of any of the above happening. That is, PG15? I agree to that. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
