On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote: > On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing <ha...@2ndquadrant.com> wrote: > > My hope was, that this contention would be the same than simply writing > > the WAL buffers currently, and thus largely hidden by the current WAL > > writing sync mechanisma. > > > > It really covers just the part which writes commit records to WAL, as > > non-commit WAL records dont participate in snapshot updates. > > 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. It has to be > done later, at the time we currently remove ourselves from the > ProcArray. Those things need not happen in the same order, as I noted > in my original post.
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 ? If the problem is with a backend which requested an "async commit", then it is free to apply it's additional local commit changes from its own memory if the global latest snapshot disgrees with it. -- ------- Hannu Krosing PostgreSQL Infinite Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/ -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers