> OK, makes sense. And still resume decoding from restart_lsn, despite having > that visibility information stashed, because we also have to rebuild the > information on invalidations for running xacts, which is not stored > persistently anywhere as decoding progresses. So for now at least it's an > optimisation to store the visibility info, since we still have go go back > and decode for invalidations anyway. Right?
Not really no. The important point isn't invalidation or anything. It's that we don't have the content & metadata of the transactions themselves. Yes, we also do re-read invalidations, but that's just a side effect.
Right, because the reorder buffer contents aren't persistent so decoding must restart at an lsn at or before the start of the oldest uncommitted xact at the time it wants to start returning committed changes to the client.
I've been looking too hard for the details and somehow managed to completely miss the blindingly obvious right in front of me. I knew that the confirmed lsn was the threshold of confirmed commit LSNs, I knew about the reorder buffer needing to accumulate changes, I knew it wasn't persistent, etc. Yet I can't pretend I didn't overlook that when looking over the xlogreader vs decoding startup, per those comments.
I don't think a succinct comment there will be useful given that it'd really just do a better job of explaining what restart_lsn is and why we start decoding there. So I guess a more detailed comment on the slot struct (not on the field, at the start) would be good. Or that README.
