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
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 |