Skip site navigation (1) Skip section navigation (2)

Re: Question Regarding Locks

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

In response to

Responses

pgsql-novice by date

Next:From: Martijn van OosterhoutDate: 2004-10-29 09:34:12
Subject: Re: Question Regarding Locks
Previous:From: Michaud, EverettDate: 2004-10-28 23:39:31
Subject: help using count in function

pgsql-general by date

Next:From: Martijn van OosterhoutDate: 2004-10-29 09:34:12
Subject: Re: Question Regarding Locks
Previous:From: Stuart BishopDate: 2004-10-29 07:22:20
Subject: Re: Comment on timezone and interval types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group