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
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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-novice by date

  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