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 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match