Re: Feature freeze date for 8.1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Feature freeze date for 8.1
Date
Msg-id 24597.1114961867@sss.pgh.pa.us
Whole thread Raw
In response to Re: Feature freeze date for 8.1  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Feature freeze date for 8.1  (<adnandursun@asrinbilisim.com.tr>)
Re: Feature freeze date for 8.1  (Hannu Krosing <hannu@skype.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> The problem, as I understand it, is that if you have a long-running 
> query and the client process disappears, the query keeps running and 
> holds whatever resources it may have until it finishes.

There is a trivial solution for this: it's called statement_timeout.

If the concern is that a process may block other processes for a long
time, what does it matter whether the client is still connected or not?
It's the long-running command in itself that is the problem.  So you
limit the time the command can run.

It might be interesting to think about a transaction_timeout as well,
to bound the time locks can be held.  But none of this has anything
to do with "high availability" as I understand the term.  It looks
more like a forcing function to make your users fix poorly-written
client software ;-)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SPI bug.
Next
From:
Date:
Subject: Re: Feature freeze date for 8.1