>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
> > >
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
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 reportin
(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, pleas
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
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,
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
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 UP
