Re: No Timeout in SELECT..FOR UPDATE

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

Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> 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 wasn't room for improvement, I was just
responding to the OP's assertion that there is "NO WAY" to do it now.

In practice though I think that a statement_timeout solves the problem
well enough. The sort of command you are going to be worried about is
something like a SELECT ... FOR UPDATE with a simple WHERE condition,
and if the normal (unblocked) execution time isn't very much less than
your expected maximum transaction time then you've got problems anyway.
Whatever sort of timeout you use, you'd have to set at some multiple of
the expected max transaction time unless you want to get unnecessary
failures. So it seems to me that there's plenty of daylight there,
and relatively little need for a per-lock timeout.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Haney 2004-02-16 16:17:50 Re: Proposed Query Planner TODO items
Previous Message Andrew Dunstan 2004-02-16 16:15:50 Re: [PATCHES] dollar quoting