(sorry for top posting -- blame apple)
I don't see anything "dangerous" with either setting. For use cases
where the backup is the primary purpose then killing queries is fine.
For use cases where the maching is a reporting machine then saving
large amounts of archived logs is fine.
Engineering is about tradeoffs and these two use cases are
intrinsically in conflict.
The alternative is postponing vacuuming on the master which is imho
even worse than the disease.
--
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
