Robert Treat
On Sunday 15 February 2004 16:36, Tom Lane wrote:
Anthony Rich <richae@optusnet.com.au> 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

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 8 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 10, '04 at 5:42a
activeFeb 17, '04 at 7:52a
posts8
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase