Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Date
Msg-id 200411250313.iAP3DNJ01731@candle.pha.pa.us
Whole thread Raw
In response to Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  ("ronzo" <m.ronzoni@nocerainformatica.net>)
Responses Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  (Rod Taylor <pg@rbt.ca>)
List pgsql-hackers
ronzo wrote:
> Hi
> 
> Was already implemented the timeout on the "SELECT ... FOR UPDATE" (non-blocking lock) and/or is possible known if
thelock 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Arnold.Zhu"
Date:
Subject: Re: How to make @id or $id as parameter name in plpgsql,is it available?
Next
From: Tom Lane
Date:
Subject: Re: plpgsql lacks generic identifier for record in triggers...