On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing <hannu@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/