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_ABORTED is allowed TRANSACTION_STATUS_SUB_COMMITTED is allowed TRANSACTION_STATUS_SUB_COMMITTED to TRANSACTION_STATUS_IN_PROGRESS is allowed (but should not be) TRANSACTION_STATUS_COMMITTED is 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_ABORTED is 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_ABORTED is 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
