On Fri, 2011-01-21 at 02:32 -0500, Dan Ports wrote:
> 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.
So T1 and T2 are already potentially unserialized and the presence of T3
causes the sequence to be "caught out" from which we must then abort T2.
The witness does not create the offence, they just report the crime.
So any xid that commits in a different sequence to the order in which
the xid was assigned creates a potential for unserialization? Or?
On HS we know the order of arrival of xids, and we know the order of
commits, so we should be able to work out which are the potentially
unserializable snapshots. That would allow us to make the standby
independent of the master, thereby avoiding all this messy information
flow.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
