Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Robert Treat
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id CABV9wwOysPdfE7D4NDWn3ghAF7fmn3Ngm2-kMyXtLxMowJFegQ@mail.gmail.com
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: unite recovery.conf and postgresql.conf  (Joshua Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Mon, Oct 31, 2011 at 3:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Oct 31, 2011 at 7:05 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> If it's possible to run a replica without having a recovery.conf file,
>> then I'm fine with your solution.  If it's not, then I find your
>> solution not to be a solution at all.
>
> Then you are fine with the solution - not mine alone, just the sum of
> everybody's inputs.
>
> So we can teach the new way, while supporting the old way a while longer.
>

In most cases we either break backwards compatibility or require some
type of switch to turn on backwards compatibility for those who want
it. While the above plan tries to do one better, it leaves me feeling
that the thing I don't like about this is that it sounds like you are
forcing backwards compatibility on people who would much rather just
do things the new way. Given that, I foresee a whole new generation of
confused users who end up setting their configs one way only to have
someone else set the same config in the other file, or some tool dump
out some config file, overriding what was really intended. This will
also make things *harder* for those tool providers you are trying to
help, as they will be forced to support the behavior *both ways*. I'd
much rather see some type of switch which turns on the old behavior
for those who really want it, because while you can teach the new
behavior, if you can't prevent the old behavior, you're creating
operational headaches for yourself.


Robert Treat
conjecture: xzilla.net
consulting: omniti.com


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: IDLE in transaction introspection
Next
From: Robert Haas
Date:
Subject: Re: IDLE in transaction introspection