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 <t...@sss.pgh.pa.us> wrote:
"Joshua D. Drake" <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
