Simon Riggs <[EMAIL PROTECTED]> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
