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

Re: incoherent view of serializable transactions

From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: incoherent view of serializable transactions
Date: 2008-12-29 17:21:12
Message-ID: CF671998-4759-43B1-BCF7-255E38046070@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Sorry for top posting -- damn phone.

The standard defines all the *other* transaction isolations in terms  
of phantom reads, dirty reads, and, uh one other phenomenon. But it  
defines serializability literally, as the transactions having the same  
effect as ift they were run serially. It explicitly says the fact that  
phantom reads can't occur in serializable is only a consequence of tfe  
definition.

And I don't see why you discard "visibility" as unimportant. All the  
transaction isolations are defined in terms of the results if the  
transactions. Those results include both the database state and the  
data returned by the queries. Otherwise "phantom read" is a  
meaningless concept.

-- 
Greg


On 29 Dec 2008, at 07:20, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> On Tuesday 23 December 2008 16:51:03 Kevin Grittner wrote:
>> If you look at the serializable queries in the original post for this
>> thread, it's not hard to see that this standard is not met.  The
>> insert of receipt 3 appears to happen before the update of the  
>> control
>> record, since it has the old deposit date.  The transaction which
>> selects from both tables sees the update to the control record, so it
>> must come after that.  Yet it doesn't see the results of the first
>> transaction.  There is no sequence of serial execution which is
>> consistent with the behavior.
>
> I am not sure yet whether or not your complaint is valid, but your  
> arguments
> are not very rigid.
>
> Serializability is not defined in terms of what is visible, but what  
> the state
> of the database is.  If you can order the transactions without  
> overlap so
> that the state of the database is the same as in your original  
> schedule, the
> schedule is serializable.  It is not of concern what was "visible" in
> between.  You may, however, be able to transform that argument to  
> proving
> that a phantom read is possible, which is how the SQL standard  
> ultimately
> defines serializability.
>
> Also note that discussing what is visible necessarily implies the  
> existence of
> another transaction that does the reading, and that transaction does  
> not
> appear to be defined in your arguments.
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

pgsql-hackers by date

Next:From: Kurt RoeckxDate: 2008-12-29 17:26:34
Subject: Re: Gcc 4.4 causes abort in plpython.
Previous:From: Andrew DunstanDate: 2008-12-29 17:20:16
Subject: Re: TODO items for window functions

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