On Fri, Apr 11, 2003 at 05:33:00PM -0600, Ed L. wrote:
> On Friday April 11 2003 4:44, elein wrote:
> > In this case, on the slave, xact2 will be commited before xact 1 is
> > begun. This seems OK to me, but I'd like some confirmation to understand
> > this. Or is this the wrong question?
>
> IMO, this is exactly what makes the analysis a little tricky for people like
> me who don't regularly live in the world of transaction minutiae.
>
> If xact2 tries to update a row already updated by xact1, xact2 will block
> until xact1 commits or rolls back, and cannot end before xact1 due to MVCC.
> If xact1 tries to update a row already updated by xact2, xact1 will block
> until xact2 is resolved.
>
> My question is, given all the ways in which these orderings can occur, which
> I think simplifies to about 3 in the case of 2 transactions updating the
> same row, is there a fool-proof ordering for replaying in batches?
Well, it seems to me that you're trying to simulate the results of READ
COMMITTED mode in SERIALISABLE mode, which would seem to me to be impossible
(in the general case) if you ask me.
You'd have to get some kind of save points where the are no outstanding
writable commits and use that to divide.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
> - Samuel P. Huntington