Re: cheaper snapshots - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: cheaper snapshots
Date
Msg-id 1311869298.3117.1532.camel@hvost
Whole thread Raw
In response to Re: cheaper snapshots  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2011-07-28 at 11:57 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <tgl@sss.pgh.pa.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
> 




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: cheaper snapshots
Next
From: Hannu Krosing
Date:
Subject: Re: cheaper snapshots