On 2016-04-04 14:36:29 +0800, Craig Ringer wrote: > On 4 April 2016 at 14:30, Andres Freund <and...@anarazel.de> wrote: > > > On 2016-04-04 14:24:52 +0800, Craig Ringer wrote: > > > I don't feel like I've grasped this properly yet. I think it's referring > > to > > > the pg_logical/snapshots/ serialization, the use of which allows us to > > > avoid doing extra work in SnapBuildFindSnapshot(...), but doesn't seem to > > > be crucial for correct function. After all, decoding still restarts at > > the > > > restart_lsn and feeds relevant xact info into the snapshot builder, > > > accumulates invalidation information, etc. > > > > restart_lsn is set to the last known point where a) all changes for > > ongoing transactions are available b) we can re-build visiblity > > information when we start reading from there. > > > > As we essentially can only start determining visibility information > > whenever processing a xl_running_xacts record. Building visibility > > information means that there has to be a xl_running_xacts to start > > from. To build full visibility information we also have to wait till we > > have seen all in-progress transactions finish. So we dump visibility > > information every now and then, so we can re-use the information we'd > > already assembled. > > > > 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
