Sorry if I'm restating the obvious, however I don't understand the confusion, as it seems the standard's definition isn't mysterious; it simply requires that the resulting state from the concurrent execution of transactions (and implicitly any subset) designated to occur at the isolation level SERIALIZABLE be equivalent to SOME LITERALLY SERIAL execution of said transactions.
Thereby although of course transactions literally executed serially comply; they need not be executed literally serially, as long as some mechanism is used to warrant that the state resulting from the completion of every such transaction in some sequence be equivalent to the literally serial execution of the transactions in the same sequence. Thereby even if only a subset of such concurrently executed transactions may be complete at some point in time, any potentially remaining such transactions may be restarted for whatever reason and remain compliant (as the resulting state from the concurrent execution of such transactions will be equivalent to some literal serial execution of said transactions upon the completion of each so executed transaction; correspondingly any implementation which can not warrant the same, is simply non-compliant). Thereby although no pre-specified completion order exists per-se, the order of completion of transactions implicitly determine if incomplete transactions may need to be restarted if dependant on a preceding completed transaction's resulting mutated state (or alternatively allowed to proceed if previously blocked on said potentially mutated state). Thereby although a collection of such concurrently executed transactions my have mutual interdependencies, each subsequent complete transaction in effect break dependency deadlocks as may otherwise logically exist; and thereby may affect optimal logical execution order of remaining such transactions potentially concurrently; and be warranted to never deadlock. I believe IMHO. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
