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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Rod Taylor <pg(at)rbt(dot)ca>, ronzo <m(dot)ronzoni(at)nocerainformatica(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Date: 2004-11-25 04:01:00
Message-ID: 24300.1101355260@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Rod Taylor wrote:
>> Anyway, it shows a situation where it would be nice to differentiate
>> between statement_timeout and lock_timeout OR it demonstrates that I
>> should be using userlocks...

> Wouldn't a LOCK NOWAIT be a better solution? That is new in 8.0.

LOCK NOWAIT is only helpful if you can express your problem as not
wanting to wait for a table-level lock. When you're trying to grab a
row-level lock via SELECT FOR UPDATE, there isn't any provision for
NOWAIT.

The notion of a global lock_timeout setting is bogus IMHO, because
every proposed application of it has failed to consider the locks taken
internally by the system. But that objection wouldn't apply to a SELECT
FOR UPDATE NOWAIT command where the "no wait" behavior only applied to
the row lock being explicitly grabbed.

I thought I remembered someone working on such a thing just recently.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-11-25 04:30:46 Re: lwlocks and starvation
Previous Message Rod Taylor 2004-11-25 03:59:18 Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE