Skip site navigation (1) Skip section navigation (2)

Re: cheaper snapshots

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 14:45:16
Message-ID: 9850.1311864316@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Hannu Krosing <hannu(at)2ndQuadrant(dot)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.  The
advantage of defining it that way is you don't have weirdly different
behaviors for sync and async transactions.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-07-28 15:06:11
Subject: Re: cheaper snapshots
Previous:From: Hannu KrosingDate: 2011-07-28 14:40:43
Subject: Re: cheaper snapshots

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group