That's my fallback position. Obviously, this will lead to false positives depending on server load. In my case, I'm targeting between 30-50 users so its likely to throw timeouts for various reasons other than locks even though my queries of interest are generally select a from b where id = c type of thing. This is a kludgy solution but its still better than writing cobol.
The bigger issue is that a timeout will not return the reason the query timed out. There are cases where I would like to run a select for update over a range of records and handle the locked records and unlocked records differently. A query that could match locked oids vs the oids I am interested in would be super. I could then aggregate my select for updates into larger queries and reap massive performance gains. Another way of putting it is this: waiting for your select to timeout is kind of like parking in Manhattan: you back your car up until you hit the next car. I would sort of like to, uh, look in the rear view mirror first. Merlin > > > > In other words, if User B attempts to select for update a record that > > user A has selected for update, it would be nice if User B's query > would > > fail with a NOTICE to act upon. > > > No idea if this is of any help, but you may have a look into > PostgreSQL 7.3 Documentation > 3.4. Run-time Configuration > STATEMENT_TIMEOUT (integer) > Aborts any statement that takes over the specified number of > milliseconds. A value of zero turns off the timer. > > Regards, Christoph > ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
