On Mon, Jan 4, 2016 at 3:05 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>> > Peter Eisentraut wrote:
>> >> So we've had several rounds of discussions about simplifying replication
>> >> configuration in general and the wal_level setting in particular. [0][1]
>> >> Let's get something going.
>> >
>> > I looked at this patch, which I think has got enough consensus that you
>> > should just push forward with the proposed design -- in particular, just
>> > remove one of archive or hot_standby values, not keep it as a synonym of
>> > the other. If we're counting votes, I prefer keeping hot_standby over
>> > archive.
>>
>> I see precisely 0 votes for that alternative upthread. I came the
>> closest of anyone to endorsing that proposal, I think, but my
>> preferred alternative is to change nothing.
>
> Hm? Perhaps the problem is that the thread stood on the shoulders of
> larger threads. Andres Freund and Magnus Hagander both expressed,
> independently, their desire to see one of these modes go away:
> http://www.postgresql.org/message-id/20150203124317.GA24767@awork2.anarazel.de
> http://www.postgresql.org/message-id/CABUevEy15Y=sF8doKjD86eujJZL=Tq2jyUSiYVkg6EVwVt=cag@mail.gmail.com
OK, I see.
> Actually, in the first of these threads
> http://www.postgresql.org/message-id/flat/20150203124317.GA24767@awork2.anarazel.de
> there's a lot of discussion about getting rid of wal_level completely
> instead, but it doesn't look like there's any movement at all in that
> direction. I think we should take this pretty small change that
> improves things a bit in that direction, then others can continue to
> propose further simplifications to our configuration in that area.
>
> We could continue to do nothing, but then we've already been doing that
> for some time and it hasn't changed things much.
True. But it hasn't really caused much trouble either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
