Re: recovery_connections cannot start (was Re: master in standby mode croaks) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Date
Msg-id l2p603c8f071004231218ub27ddcd0wb4ebc699d18b3ffe@mail.gmail.com
Whole thread Raw
In response to Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Fri, Apr 23, 2010 at 3:11 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
>> we have a consensus behind changing it, which it's starting to
>> sound like we do.
>
> I think you misread the +1s from Masao and myself.
>
> Those confusing things are options and I want them to remain optional,
> not compressed into a potentially too simple model based upon how the
> world looks right now.

I didn't, but Heikki, Kevin and Tom seem to be on the other side, so
we at least have to consider where to go with it.  We're going to need
a bunch of GUCs any way we slice it.  The issue is whether there's a
way to slice it that involves fewer AND and OR operators that have to
be understood by users.  I'm still unconvinced of our ability to come
up with a solid design in the time we have, but I think it would make
sense to listen to proposals people want to make.  I poked some holes
in Heikki's design from this morning (which was, more or less, my
design from last week) but that doesn't mean they can't be plugged.

...Robert


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Next
From: Tom Lane
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)