> > begin; > > select ... for update; > > update ... set ... where > > my_pk=<my_pk_value> > > AND > > xmin=<the_old_xmin> > > I think you can skip the SELECT FOR UPDATE altogether if you do it that > way. Otherwise it looks fine. Except that there will be other clients accessing those rows, too, of which I cannot be sure that they employ the same (or even adequate) locking procedures. So I should still lock the row for good measure, right ?
The docs say that XMIN is the transaction ID of the *inserting* transaction for this row version. IOW updates will change XMIN. Will XMIN also be changed by a *deleting* transaction ? I guess it depends on how deletion is handled: Either the *unchanged* row version is marked as deleted (hence XMIN would not change) OR a new row version is created and marked deleted (which would indeed change xmin). IOW, can I also detect my row being *deleted* from under me by another transation by way of checking XMIN ? Else I would likely need to check XMAX, too. Thanks for your help, Karsten Hilbert, MD http://www.gnumed.org -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
