From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Question Regarding Locks |
Date: | 2004-10-29 07:22:42 |
Message-ID: | 20041029092242.D624@hermes.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-novice |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2004-10-29 09:34:12 | Re: Question Regarding Locks |
Previous Message | Stuart Bishop | 2004-10-29 07:22:20 | Re: Comment on timezone and interval types |
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2004-10-29 09:34:12 | Re: Question Regarding Locks |
Previous Message | Michaud, Everett | 2004-10-28 23:39:31 | help using count in function |