On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
> We have enough information in the standby to reconstruct all writes done
> in the master. I gather that's not enough, in order to roll back
> read-only transaction T3 on the standby which would see an anomaly, we'd
> also need to know what reads T1 and T2 did in the master. Is that correct?
That's some of the information we need, but it's not enough...
The problem is that the conflict might not be discovered until after T3
(the reader) commits. In that case, it's too late to abort T3, so you'd
need to roll back T2 instead. But that means a read-only transaction on
the slave has to be able to cause a concurrent read-write transaction
on the master to abort, which brings with it no end of problems.
To make that a little more concrete, let me borrow Kevin's favorite
batch processing example...
[master] T2: BEGIN[master] T2: SELECT FROM control[master] T1: BEGIN[master] T1: UPDATE control[master] T1: COMMIT
[slave]T3: BEGIN [slave] T3: SELECT FROM control, receipt [slave] T3: COMMIT[master] T2: INSERT INTO receipt[master]
T2:COMMIT
If this all happened at the master, T2 would get rolled back when it
tries to do its INSERT. (I just tried it.) But if T3 happened on the
slave, the master doesn't know that it read both tables, nor does the
slave know at the time it's executing T3 that it's going to conflict
with T2.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/
