On Wed, Jun 21, 2006 at 07:44:36PM +1000, Ian Haywood wrote:
> Okay, let's think about this. We all accept the need for XMIN, it's explicit > locking > we are querying. yes > Imagine two transactions running in parallel. Postgres forces them to > serialize, If so configured which we do. > (randomly if they hit the server at *exactly* the same time) > Both do > UPDATE foo SET A=B,C=D WHERE pk=123 and xmin=456; > > If we are in read-committed mode, one query sees the result of the other > (made to wait if necessary), > and so fails (Cursor.rowcount=0) as xmin doesn't match anymore. It doesn't "fail", it just updates zero rows - which is just a nitpick difference but needs to be checked for explicitely. > In serialisation mode, they don't see each others results, instead one will > fail > with a serialisation error, and forced to try again, whereupon it will fail > (as it has now seen the results of the other) yes Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
