[EMAIL PROTECTED] wrote: > hash would tell you the row is different, but doesn't offer ordering , which > sequence numbers do.
Ordering is not important here - the purpose of checking the hash is to ensure that the changes which the user has just asked the system to commit are based on the most up-to-date version of the record. If the hash has changed, the system needs to re-read the record and present the updated (by someone else) information to the user and tell them to review their edits in the light of the new information. Tim C > *On Thu Jun 22 3:53 , Tim Churches sent: > > * > > Ian Haywood wrote: > > > > Tim Churches wrote: > >> Karsten Hilbert wrote: > >>> On Tue, Jun 20, 2006 at 10:38:29PM +1000, Tim Churches wrote: > >>> > >>>> What is wrong with just using a transaction. If the row is locked by > >>>> another transaction writing to it, then the transaction will abort. > No > >>>> need to mess around with explicit row locks, is there? > > Okay, let's think about this. We all accept the need for XMIN, it's > explicit locking > > we are querying. > > > > Imagine two transactions running in parallel. Postgres forces them to > serialize, > > (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. > > 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) > > The docs state that UPDATE and SELECT FOR UPDATE operate in the same > way. > > Thanks. > > One other thought: is it wise to use xmin as the row "state" identifier? > We've been stung by our use of OIDs to identify updated rows - user > access to the OID column is now deprecated in PG 8.1 and will disappear > entirely in future versions. Maybe a hash on the data read originally > from the row might be better, and that would also work where data is > read from many different tables to form the patient "row" object by your > middleware. > > Tim C > > > > _______________________________________________ > Gnumed-devel mailing list > [email protected] > <javascript:top.opencompose('[email protected]','','','')> > http://lists.gnu.org/mailman/listinfo/gnumed-devel > > <parse.pl?redirect=http%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fgnumed-devel> > > _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
