On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing <hannu@2ndquadrant.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
