On Thu, 2011-07-28 at 10:45 -0400, Tom Lane wrote: > Hannu Krosing <ha...@2ndquadrant.com> writes: > > On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote: > >> I'm confused by this, because I don't think any of this can be done > >> when we insert the commit record into the WAL stream. > > > The update to stored snapshot needs to happen at the moment when the WAL > > record is considered to be "on stable storage", so the "current > > snapshot" update presumably can be done by the same process which forces > > it to stable storage, with the same contention pattern that applies to > > writing WAL records, no ? > > No. There is no reason to tie this to fsyncing WAL. For purposes of > other currently-running transactions, the commit can be considered to > occur at the instant the commit record is inserted into WAL buffers. > If we crash before that makes it to disk, no problem, because nothing > those other transactions did will have made it to disk either.
Agreed. Actually figured it out right after pushing send :) > The > advantage of defining it that way is you don't have weirdly different > behaviors for sync and async transactions. My main point was, that we already do synchronization when writing wal, why not piggyback on this to also update latest snapshot . -- ------- Hannu Krosing PostgreSQL (Infinite) Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
