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

Re: cheaper snapshots

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 16:08:18
Message-ID: 1311869298.3117.1532.camel@hvost (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 2011-07-28 at 11:57 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
> 
> Right, but if the visibility order were *defined* as the order in which
> commit records appear in WAL, that problem neatly goes away.  It's only
> because we have the implementation artifact that "set my xid to 0 in the
> ProcArray" is decoupled from inserting the commit record that there's
> any difference.

Yes, as I explain in another e-mail, the _only_ one for whom the
transaction is not yet committed is the waiting backend itself. for all
others it should show as committed the moment after the wal record is
written.

It's kind of "local 2 phase commit" thing :)

> 
> 			regards, tom lane
> 



In response to

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2011-07-28 16:48:24
Subject: Re: cheaper snapshots
Previous:From: Hannu KrosingDate: 2011-07-28 16:05:51
Subject: Re: cheaper snapshots

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