On Sat, Jan 3, 2026 at 9:52 AM Andrey Borodin <[email protected]> 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
