Re: confusing results from pg_get_replication_slots()

On Sat, Jan 3, 2026 at 9:52 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> Slot state is a mix of 3 values here: WAL reservation, WAL availability, xmin reservation.
> WAL reservation is 3-state value: "reserving", "extended reserving", "not reserving".
> WAL availability is binary. Always true if reserving.
> xmin reservation is binary, always true if WAL was continously available (or is it connected at all?).
>
> "unreserved" slot does not reserve WAL, but holds xmin. WAL must be avaliable.
> "lost" does not reserve WAL, and also does not hold xmin. WAL might be available, might be unavailable.
>
> Is it possible to report state of the slot consistently without race conditions?

I don't know. I think that on master we should seriously consider
reporting invalidated slots in some clearly-distinguishable way, e.g.
report "invalidated" rather than "lost". The fact that the slot is
invalidated means that whether or not the WAL is still available is a
moot point. In the back-branches, I think introducing a new possible
value of that column is too much, but I think that display "lost" is
clearly better than displaying "unreserved," since the only reason
that we ever do the latter is due to a weird exception that is
intended to catch race conditions which really makes no sense for an
invalidated slot, where recovery is not possible.

--
Robert Haas
EDB: http://www.enterprisedb.com