>Robert Treat...
> 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.
> > >
Well, it shouldn't be too much of a patch - just cloning the code?
Perhaps they can start in development without it and we'll patch it in
later.
> > > 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.
>
Agreed - and this is important! I thought we'd done NOWAIT on the SELECT...
Oh well, 8.1 will be better still.
Best Regards, Simon Riggs
