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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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