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 order in all equivalent 
serial schedule doesn't match their commit order, any snapshot taken between 
the two commits don't represent 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 
the master, but that could be handled by the recovery process without having to 
report anything back to the master, and without logging 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 does the necessary conflict flagging in 
case the write happens (in wall clock time) after the slave, mimicking what the 
writing transaction 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 can detect 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 patch to judge that.

best regards,
Florian Pflug


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to