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
Robert Treat [EMAIL PROTECTED] writes:
On Sunday 15 February 2004 16:36, Tom Lane wrote:
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.
I didn't say that there
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
Hi Guys,
I have a suggestion for fixing a long-term and painful
problem in PostgreSQL that is holding up many very
important commercial projects, including ours!
This problem has been reported numerous times:
When one process has a row lock on one or more rows
in a table, using SELECT...FOR
Anthony,
What you need is a NO WAIT option.
This is already on the TODO list.
This feature should be implemented as GUC (see TODO list).
I don't think that a timeout would be accepted by the core team (doesn't
make too much sense to me either). Telling PostgreSQL not to wait for
certain locks
On Tue, 10 Feb 2004, Anthony Rich wrote:
In other words, by the time the second process has run the
SELECT...FOR UPDATE statement, it's too late!! This
second process is now locked forever, waiting for the
Or until statement_timeout is reached if it's set to a non-zero value.
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
(1) Re-write the SELECT...FOR UPDATE SQL code, to
return with an exception or error if it cannot immediately
secure the lock, OR:
You could use SET STATEMENT_TIMEOUT...
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
