Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
>> the serializable transaction looks at is locked against updates
>> 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
>> scan is required, the entire table is locked against all
>> modifications.  (That's right, it is not unusual to have entire
>> 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
> 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.

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group