On Fri, Feb 11, 2022 at 6:22 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Fri, Feb 11, 2022 at 3:33 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > >
> IIUC, the issue can happen while the walreceiver failed to get WAL > from primary for whatever reasons and its status is not > WALRCV_STOPPING or WALRCV_STOPPED, and the startup process moved ahead > in WaitForWALToBecomeAvailable for reading from archive which ends up > in this assertion failure. ITSM, a rare scenario and it depends on > what walreceiver does between failure to get WAL from primary and > updating status to WALRCV_STOPPING or WALRCV_STOPPED. > > If the above race condition is a serious problem, if one thinks at > least it is a problem at all, that needs to be fixed. I don't think we can design a software which has open race conditions even though they are rarely occurring :) I don't think > just making InstallXLogFileSegmentActive false is enough. By looking > at the comment [1], it doesn't make sense to move ahead for restoring > from the archive location without the WAL receiver fully stopped. > IMO, the real fix is to just remove WalRcvStreaming() and call > XLogShutdownWalRcv() unconditionally. Anyways, we have the > Assert(!WalRcvStreaming()); down below. I don't think it will create > any problem. If WalRcvStreaming() is returning false that means walreceiver is already stopped so we don't need to shutdown it externally. I think like we are setting this flag outside start streaming we can reset it also outside XLogShutdownWalRcv. Or I am fine even if we call XLogShutdownWalRcv() because if walreceiver is stopped it will just reset the flag we want it to reset and it will do nothing else. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com