On Jan21, 2011, at 10:19 , Heikki Linnakangas wrote:
> On 21.01.2011 11:10, Simon Riggs wrote:
>> So any xid that commits in a different sequence to the order in which
>> the xid was assigned creates a potential for unserialization? Or?
>
> It's not the order in which the xid was assigned that matters, but the order the transactions started and got their
snapshots.The xids might be assigned a lot later, after the transactions have already read data.
Any pair of concurrent transactions on the master between which r/w-dependencies exist are a potential risk. If their
orderin all equivalent serial schedule doesn't match their commit order, any snapshot taken between the two commits
don'trepresent a fully consistent view of the database.
Hm, wait a minute... Thinks...
Since transactions on the slave don't write, they really don't need to be aware of any SIREAD locks taken on the
master,right? We'd still need to detect conflicts between SIREAD locks taken on the slaves and writes by transaction on
themaster, but that could be handled by the recovery process without having to report anything back to the master, and
withoutlogging SIREAD lock acquisitions. So, how about the following
A) We log r/w-dependencies between transactions committed on the master in the WAL, probably in the COMMIT record
B) SERIALIZABLE queries on the slave use the SIREAD lock machinery like they'd do on the master. The recovery process
doesthe necessary conflict flagging in case the write happens (in wall clock time) after the slave, mimicking what the
writingtransaction had done on the master had it seen the SIREAD lock
C) By using the r/w-dependency information from the WAL plus the r/w-dependency information generated on the slave we
candetect dangerous situations on the slave, and abort the offending query on the slave.
(A) and (B) seem quite straight-forward. Regarding (C), I'm not familiar enough with the inner workings of the SSI
patchto judge that.
best regards,
Florian Pflug
