>>> Stephan Szabo <ssz...@megazone.bigpanda.com> wrote: > On Tue, 23 Dec 2008, Kevin Grittner wrote: > >> The page locking provides this because every index page or data page >> the serializable transaction looks at is locked against updates until >> the end of the transaction. If it can see all the COLUMN=0 rows >> through an index, the index locks protect the transaction. If a table >> scan is required, the entire table is locked against all >> modifications. (That's right, it is not unusual to have entire tables >> locked against any modification until the end of a database >> transaction.) > > Well, predicate locking for serializable also should only lock the > appropriate conditions. Getting a deadlock between two serializable > transactions for conditions that can be serialized would seemingly also be > disallowed by the definition of serializable since there would exist no > serial ordering of the transactions that has that effect. Clever. If a DBMS is capable of reporting that it was unable to serialize a transaction in a situation where there is a logical possibility that a different implementation might have succeeded, it hasn't implemented true serializable transactions? That strikes me as being on a level with Codd's assertion that any database which takes two different statements which can be proven to be logically identical and runs one with a different plan than the other should not be called relational. (i.e., possibly true from a technical perspective, but hardly useful in the real world.) Perhaps it would be best to accept this as proof that there is no current DBMS implementing true serializable transactions and move on to the issue of documenting real difference between PostgreSQL other products which come closer to compliance, so that real people converting from those products don't suffer real production problems. As I see it, that's what matters. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
