>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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings