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
>
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 |