(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 <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
