Re: incoherent view of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Emmanuel Cecchet" <manu(at)frogthinker(dot)org>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: incoherent view of serializable transactions
Date: 2008-12-23 17:58:29
Message-ID: 4950D265.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lawrence, Ramon 2008-12-23 18:12:22 Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets
Previous Message Simon Riggs 2008-12-23 17:53:55 Re: Synchronous replication, network protocol