Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby.

On Wed, 2008-10-22 at 17:16 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Wed, 2008-10-22 at 16:41 -0400, Tom Lane wrote:
> >> Hmm, but then why did we not see the same thing before?
>
> > The failure definitely came from trying to set SUBCOMMITTED on a
> > transaction already committed.
>
> Ah, I see: prior versions did not bother to make a WAL entry for a
> subcommit, so there was no case where a replay would try to reverse
> the later state change to committed.
>
> I see from a quick look in xact.c that CommitSubTransaction no longer
> marks the subxact as subcommitted at all, which makes me wonder what is
> the point of even having the state. If you intend that we are going to
> rely 100% on in-memory state to detect our own subcommitted
> transactions, then why isn't it sufficient to mark the parent committed
> and then mark the subtransactions committed? An onlooker would see a
> subtransaction go directly from IN_PROGRESS to COMMITTED, but if the
> onlooker is too slow to catch the now-very-transient SUBCOMMITTED
> state, that's what he'd see anyway.

My interest was really in maintaining ultra-correctness, while removing
the need to WAL log subcommits for Hot Standby. I think I achieved that,
almost, but if you see further optimizations that is good too.

My understanding is that if we just mark the top-level as committed and
then mark subtransactions as committed that it would be possible to have
two observers conclude different things, which is therefore not atomic:
* backend1 look at top-level xid and see it as committed
* backend2 look at subtransaction and see it as in-progress
especially if the two xids were on separate pages.
Which sounds pretty bad to me.

The problem is what happens across clog pages. We only mark subcommitted
across subtransactions when we access more than one page. It's a very
transient state, but it prevents the situation where multiple observers
see different results.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support