Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: ronzo <m(dot)ronzoni(at)nocerainformatica(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Date: 2004-11-25 03:13:23
Message-ID: 200411250313.iAP3DNJ01731@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ronzo wrote:
> Hi
>
> Was already implemented the timeout on the "SELECT ... FOR UPDATE" (non-blocking lock) and/or is possible known if the lock exist on the specified ROW before executing the SELECT?
>
> Please note: ours need is the timeout/verify at the ROW level, not at the table level.
>
> Is already OK? Is in the TODO list?
> May you suggest an alternative method?

We have discussed this at length and no one could state why having an
timeout per lock is any better than using a statement_timeout.

We can not do a NOWAIT on a single SELECT because there are alot of
locks used even for a select and having them fail randomly would be
useless.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-11-25 03:24:26 Re: plpgsql lacks generic identifier for record in triggers...
Previous Message Francisco Figueiredo Jr. 2004-11-25 02:15:41 Re: How to make @id or $id as parameter name in plpgsql,