>Robert Treat > On Sunday 15 February 2004 16:36, Tom Lane wrote: > > Anthony Rich <[EMAIL PROTECTED]> writes: > > > When one process has a "row lock" on one or more rows > > > in a table, using "SELECT...FOR UPDATE" in default lock > > > mode, another process has NO WAY of aborting from the > > > same request, and reporting to the user that this record > > > is already locked, reserved, or whatever you want to call it. > > > > Not so. See the statement_timeout parameter. > > > >what is > needed > i think is a lock_timeout, which times out soley for cases where the lock > can > not be aquired in a speedy manner.
Perhaps another way is to specify that you do not wish to wait at all. Oracle and DB2, possibly others, allow the use of the NOWAIT operator, applied to a preceding LOCK statement, which acts just as it says. If it encounters a lock, it returns immediately. This then returns control immediately to the application, so that it can report to the user to get further instructions. My understanding is that implementing that might require some fairly basic changes to the internal locking API - maybe not too complex, but it might cause many changes; I'd vote for it, but don't hold your breath... Alternatively, don't use the SELECT..FOR UPDATE metaphor, try another design that doesn't require this style of locking. Application level locking can get you round many problems - the database can't do everything. Best regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
