Re: No Timeout in SELECT..FOR UPDATE

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Anthony Rich <richae(at)optusnet(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: No Timeout in SELECT..FOR UPDATE
Date: 2004-02-16 15:53:11
Message-ID: 200402161053.11142.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sunday 15 February 2004 16:36, Tom Lane wrote:
> Anthony Rich <richae(at)optusnet(dot)com(dot)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.
>

ISTM this is the same problem with the stacked up vacuums... and
statement_timeout doesnt solve it. If someone sets statement_timeout =
<small number> then true, there lock waiting will timeout if it hits the
statement_timeout limit, but if the statement itself just takes longer than
statement_timeout in the processing itself, then it also bombs out... and you
have no way to really differentiate the two different cases. 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.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-02-16 16:07:46 Re: [HACKERS] dollar quoting
Previous Message Bruce Momjian 2004-02-16 15:48:11 Re: [HACKERS] dollar quoting