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? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
