Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Devrim GUNDUZ <devrim(at)gunduz(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
Date: 2004-09-12 12:49:16
Message-ID: 200409120849.17415.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday 10 September 2004 17:58, Bruce Momjian wrote:
> Devrim GUNDUZ wrote:
> > Hi,
> >
> > AFAIR there was a thread about "SELECT FOR UPDATE NOWAIT" availability in
> > {7.5,8.0}, 7-8 months ago.
> >
> > Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
> > SELECT ... NOWAIT one. Today I got a request for this; and it was
> > reported that this feature will be used in a huge project.
> >
> > If there is an unapplied patch that I've missed (even though I didn't see
> > one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
> > know it -- taking all the risks, surely.
>
> I don't know of any patch done. The solution suggested was to use
> statement_timeout before the SELECT FOR UPDATE. I am not 100% excited
> about that because there is no way to know if the query is slow because
> of a lock or just system slowness, but the logic is that you really
> don't care why you have failed to do a lock or not, just that the query
> is taking a long time.

Hmm... this seems the exact opposite of how I would tend to think the feature
would be used... ie. you don't really care how long the query takes, just
that you can't get the lock.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2004-09-12 13:31:39 Re: Indexed views?
Previous Message Bruce Momjian 2004-09-12 10:52:13 Re: pgxs default installation + various fixes