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

Re: cheaper snapshots

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 15:06:11
Message-ID: CA+Tgmoa=V2NK7wD2sM7qFTZJerpYiEtSx_kM86AG3GV3peOH3A@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.
>
> But should we rethink that?  Your point that hot standby transactions on
> a slave could see snapshots that were impossible on the parent was
> disturbing.  Should we look for a way to tie "transaction becomes
> visible" to its creation of a commit WAL record?  I think the fact that
> they are not an indivisible operation is an implementation artifact, and
> not a particularly nice one.

Well, I agree with you that it isn't especially nice, but it seems
like a fairly intractable problem.  Currently, the standby has no way
of knowing in what order the transactions became visible on the
master.  Unless we want to allow only SR and not log shipping, the
only way to communicate that information would be to WAL log it.
Aside from the expense, what do we do if XLogInsert() fails, given
that we've already committed?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2011-07-28 15:10:28
Subject: Re: cheaper snapshots
Previous:From: Tom LaneDate: 2011-07-28 14:45:16
Subject: Re: cheaper snapshots

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