Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date
Msg-id 4A08B5E4.4050009@agliodbs.com
Whole thread Raw
In response to Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Hans-Juergen Schoenig <postgres@cybertec.at>)
List pgsql-hackers
On 5/11/09 4:25 PM, Tom Lane wrote:
> Josh Berkus<josh@agliodbs.com>  writes:
>> I can see Zoltan's argument: for web applications, it's important to
>> keep the *total* wait time under 50 seconds for most users (default
>> browser timeout for most is 60 seconds).
>
> And why is that only about lock wait time and not about total execution
> time?  I still think statement_timeout covers the need, or at least is
> close enough that it isn't justified to make lock_timeout act like that
> (thus making it not serve the other class of requirement).

That was one of the reasons it's "completely and totally unworkable", as 
I mentioned, if you read the next sentence.

The only real answer to the response time issue is to measure total 
response time in the middleware.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Show method of index
Next
From: Tom Lane
Date:
Subject: Re: DROP TABLE vs inheritance