Re: Hot Standby (v9d) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hot Standby (v9d)
Date
Msg-id 21473.1233172578@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hot Standby (v9d)  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Hot Standby (v9d)  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Hot Standby (v9d)  (Greg Stark <greg.stark@enterprisedb.com>)
Re: Hot Standby (v9d)  (Greg Stark <greg.stark@enterprisedb.com>)
Re: Hot Standby (v9d)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Hot Standby (v9d)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby (v9d)
Next
From: Aidan Van Dyk
Date:
Subject: Re: Hot Standby (v9d)