Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation

On Tue, Jul 21, 2026 at 6:12 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

>
> IIUC it's too late to inform the primary during
> XLOG_LOGICAL_DECODING_STATUS_CHANGE redo; the standby replays that
> record only after the primary has disabled logical decoding, so WAL
> lacking the information required for logical decoding has already been
> generated. Once such a gap exists, the standby's slots cannot decode
> past it even if the primary re-enabled logical decoding in response,
> so we would have to invalidate them anyway.
>
> Alternatively, standbys could proactively tell the primary about their
> slots (like hot_standby_feedback), but I don't think this can be made
> reliable. With cascaded standbys the information has to be propagated
> up through each level, and the propagation lag leaves an unavoidable
> race: by the time the primary learns that a downstream server still
> needs logical WAL, its slots may already be gone, or a new slot could
> be created right after the primary decided to disable.
>

makes sense.

--
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/
" Maybe that's what Batman is about. Not winning. But failing, and getting
back up. "