On Wed, Sep 16, 2026 at 4:04 AM surya poondla <[email protected]> wrote: > >> >> The comments above drop_local_obsolete_slots() already >> anticipate standby-side invalidation from max_slot_wal_keep_size, but >> assume the slot gets recreated successfully in the next cycle, which >> doesn't hold when the remote isn't advancing. > > > If the two are equivalent, then that comment looks like the concrete thing > worth fixing, since it's the assumption that misleads. A note in the docs > that a synced slot can be invalidated on the standby, and that recovering it > needs action on the primary, might help too, given users can't drop it > themselves. >
+1. It would be good to update the comments above drop_local_obsolete_slots() to cover the new GUC as well. We already have guidance in the docs for such failure scenarios at [1]. I think it broadly covers this GUC case too, but it can be reviewed for completeness. [1] https://www.postgresql.org/docs/current/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION -- Thanks, Nisha
