2010/5/25 Dan Ports <d...@csail.mit.edu>: > On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote: > >> I don't understand the problem. According to me, in the context of >> SSI, a read-only slave can just map SERIALIZABLE to the technical >> implementation of REPEATABLE READ (i.e., the currently-existing >> "SERIALIZABLE"). The union of the transactions on the master and the >> slave(s) will still exhibit SERIALIZABLE behavior because the >> transactions on the slave cannot write anything and are therefore >> irrelevant. > > This, unfortunately, isn't true in SSI. > > Consider read-only transactions on a single node SSI database -- the > situation is the same for read-only transactions that run on a slave. > These transactions can be part of anomalies, so they need to be checked > for conflicts and potentially aborted. > > Consider Kevin's favorite example, where one table contains the current > date and the other is a list of receipts (initially empty). > T1 inserts (select current_date) into receipts, but doesn't commit > T2 increments current_date and commits > T3 reads both current_date and the receipt table > T1 commits > > T3, which is a read-only transaction, sees the incremented date and an > empty list of receipts. But T1 later commits a new entry in the > receipts table with the old date. No serializable ordering allows this. > However, if T3 hadn't performed its read, there'd be no problem; we'd > just serialize T1 before T2 and no one would be the wiser. > > SSI would detect a potential conflict here, which we could resolve by > aborting T3. (We could also abort T1, but if this is a replicated > system this isn't always an option -- T3 might be running on the > slave, so only the slave will know about the conflict, and it can't > very well abort an update transaction on the master.)
Ah, indeed. I made the same reasoning mistake as Florian (presumably) did: I didn't think of the fact that the read-only transaction doesn't need to be the pivot. Nicolas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
