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. "
