> On 3 Jan 2026, at 18:12, Robert Haas <[email protected]> wrote:
>
> What I think is *really bad* about this situation is that, when the
> slot is invalidated, showing it as unreserved makes it still look
> potentially useful. But no matter whether the WAL is present or not,
> the slot neither serves to reserve WAL or to hold back xmin once
> invaliated. Therefore it is not useful. The user would be better off
> using no slot at all, in which case xmin would be held back and WAL
> reserved at least while the walreceiver is connected. It is not a
> question of whether the user can stream from the slot: the user
> doesn't need a slot to stream. It's a question of whether the user
> erroneously believes themselves to be protected against something when
> in fact they are using a defunct slot that is worse than no slot at
> all.
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?
Best regards, Andrey Borodin.
