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