Re: Assertion failure in WaitForWALToBecomeAvailable state machine

At Tue, 13 Sep 2022 11:56:16 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Tue, Sep 13, 2022 at 8:52 AM Noah Misch <noah(at)leadboat(dot)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