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 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
