On Tue, Jul 21, 2026 at 6:12 AM Masahiko Sawada <[email protected]> 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. "
