Re: Timeline following for logical slots

On 4 April 2016 at 14:43, Andres Freund <andres(at)anarazel(dot)de> wrote:

> > 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.

Thanks for your patience.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services