Put another way: your characterization is no more true than claiming
there's no "safe" setting for statement_timeout since a large value
means clog could overflow your disk and your tables could bloat.
(I note we default statement_timeout to off though)
--
Greg
On 28 Jan 2009, at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> On Wed, 2009-01-28 at 19:27 +0000, Simon Riggs wrote:
>>> On Wed, 2009-01-28 at 18:55 +0000, Gregory Stark wrote:
>>>> I still *strongly* feel the default has to be the
>>>> non-destructive conservative -1.
>>>
>>> I don't. Primarily, we must support high availability. It is much
>>> better
>>> if we get people saying "I get my queries cancelled" and we say
>>> RTFM and
>>> change parameter X, than if people say "my failover was 12 hours
>>> behind
>>> when I needed it to be 10 seconds behind and I lost a $1 million
>>> because
>>> of downtime of Postgres" and we say RTFM and change parameter X.
>
>> If the person was stupid enough to configure it for such as thing
>> they
>> deserve to the lose the money.
>
> Well, those unexpectedly cancelled queries could have represented
> critical functionality too. I think this argument calls the entire
> approach into question. If there is no safe setting for the parameter
> then we need to find a way to not have the parameter.
>
> regards, tom lane
