On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote:
> Basically, when we already have a pivot, but no transaction has yet
> committed, we wait to see if TN commits first. If so, we have a
> problem; if not, we don't. There's probably some room for improving
> performance by cancelling T0 or T1 instead of TN, at least some of
> the time; but in this pass we are always cancelling the transaction
> in whose process we detect the need to cancel something.
Well, in this case we do clearly have a problem, because the result is
not equal to the serial execution of the transactions in either order.
So the question is: at what point is the logic wrong? It's either:
1. PreCommit_CheckForSerializationFailure() is missing a failure case.
2. The state prior to entering that function (which I believe I
sufficiently described) is wrong.
If it's (2), then what should the state look like, and how is the GiST
code supposed to result in that state?
I know some of these questions are answered in the relevant research,
but I'd like to discuss this concrete example specifically.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
