Re: cheaper snapshots

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 14:40:43
Message-ID: 1311864043.3117.1391.camel@hvost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-28 14:45:16 Re: cheaper snapshots
Previous Message pasman pasmański 2011-07-28 14:40:07 Netbeans and postgres