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

Re: incoherent view of serializable transactions

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "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 12:20:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-12-29 12:25:47
Subject: Re: Gcc 4.4 causes abort in plpython.
Previous:From: Peter EisentrautDate: 2008-12-29 11:25:12
Subject: About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)

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