From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(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-12-02 04:40:28 |
Message-ID: | 200412020440.iB24eSD07146@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
Added to TODO:
* Allow FOR UPDATE queries to do NOWAIT locks
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-12-02 04:46:00 | Re: VACUUM FULL FREEZE is unsafe |
Previous Message | Jan Wieck | 2004-12-02 04:25:59 | Re: Error handling in plperl and pltcl |