>>> Peter Eisentraut <pete...@gmx.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. I don't read the standard that way. I'll repeat the relevant part of the standard: "The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins." There is no end-to-end sequence in which the transactions listed in my original email can be run that will produce the same effect that you get within PostgreSQL, at least if you consider the results of a SELECT statement to be significant. (I do.) > 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. On what do you base that assertion? > 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. No it isn't. The above quoted text is. > 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. It was this one, in my original post: start transaction isolation level serializable ; select * from ctl; -- (deposit_date shows as 2008-12-23) select * from receipt; -- (Only receipts 1 and 2 show for 2008-12-22.) commit; -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers