On Thu, 2008-10-23 at 04:38 +0100, Simon Riggs wrote:
> > That means that out of the four state transitions that are
> > disallowed by the original coding of that Assert, you are now having to
> > consider two as legal. I don't like that, and I like even less that
> > it's not even trying to determine whether this is a replay-driven
> > change.
Possible state changes
TRANSACTION_STATUS_IN_PROGRESS to TRANSACTION_STATUS_IN_PROGRESS is allowed TRANSACTION_STATUS_COMMITTED is allowed
TRANSACTION_STATUS_ABORTEDis allowed TRANSACTION_STATUS_SUB_COMMITTED is allowed
TRANSACTION_STATUS_SUB_COMMITTED to TRANSACTION_STATUS_IN_PROGRESS is allowed (but should not be)
TRANSACTION_STATUS_COMMITTEDis allowed TRANSACTION_STATUS_ABORTED is allowed TRANSACTION_STATUS_SUB_COMMITTED is
allowed
TRANSACTION_STATUS_COMMITTED to TRANSACTION_STATUS_IN_PROGRESS is disallowed TRANSACTION_STATUS_COMMITTED is allowed
TRANSACTION_STATUS_ABORTEDis disallowed TRANSACTION_STATUS_SUB_COMMITTED is ignored in redo only
TRANSACTION_STATUS_ABORTED to TRANSACTION_STATUS_IN_PROGRESS is disallowed TRANSACTION_STATUS_COMMITTED is disallowed
TRANSACTION_STATUS_ABORTEDis allowed TRANSACTION_STATUS_SUB_COMMITTED is disallowed
So out of 16 possible state change requests 10 were previously allowed,
one of which was allowed but should not have been.
This patch allows 1 additional legal state change request, now in redo
only.
There are still 5 disallowed state changes, plus another one disallowed
in normal running. That seems fine.
> Presumably you would like to see an additional parameter to allow that
> test to be more strictly determined?
>
> Bug fix v2 patch enclosed, mostly API changes.
I suggest a third version with these changes:
* Write the SUBCOMMITTED to COMMIT transition as a no-op during redo
rather than as an Assert. This prevents a transition from COMMIT to
SUBCOMMIT to ABORT. By making it a no-op the attempt to set COMMIT to
SUBCOMMIT never causes a failure, but it doesn't take place either.
* Disallow SUBCOMMITTED to IN_PROGRESS transition via an Assert.
What do you think?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
