Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Date: 2010-04-29 09:55:08
Message-ID: 4BD9577C.90803@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs wrote:
> On Thu, 2010-04-29 at 10:55 +0300, Heikki Linnakangas wrote:
> 
>> Should we change the default to recovery_connections=off ? It is a quite
>> big change in default behavior over previous releases that hot standby
>> is enabled by default, so maybe that would be the right thing to do anyway.
>>
>> Or maybe add a hint to the above, "disable hot standby by setting
>> recovery_connections=off, or set wal_level='hot_standby' in the primary"
> 
> I've been waiting for this suggestion, a clear knock-on effect from your
> earlier changes. If we just have a static default its bad either way.
> 
> The most sensible way is to make the default act intelligently depending
> upon what it finds in the control file. If WAL contains hot_standby
> info, then recovery_connections should be on by default, though can be
> turned off explicitly if required. If WAL does not contain hot_standby
> info we then we throw a WARNING and continue as if recovery_connections
> = off, or if recovery_connections is specified explicitly then we should
> throw an ERROR so that the user knows it won't be possible to use this.
> I think that means we'd need to change recovery_connections to have 2 or
> 3 values, but non-boolean:
> recovery_connections = auto (default) | off
> or
> recovery_connections = auto (default) | on | off
>

Seems overly complicated. It would be simpler to just set it 'off' by
default.

If it's 'off' by default, and you want to use hot standby, you will
notice quickly that the server doesn't accept connections, and you
switch it on. If it's 'on' (or 'auto'), you might not realize that your
standby server is accepting connections, when you only wanted to set it
up as a warm standby server for high availability.

The 'auto' mode just makes it more surprising. Connections might be
allowed at first, but when someone switches wal_level in the primary for
some reason, your reporting standby is up, but no longer allows
connections. And vice versa, if you set up a warm standby server for
high availability where you don't want to allow connections, and someone
flips the wal_level switch in the master, the standby suddenly starts
accepting connections.

I can't imagine a situation where "allow connections if the WAL allows
it" would be a sensible setting. If there is one, we could have an
'auto' mode, but not as the default.

> and I would suggest removing it from postgresql.conf.sample

-1. Why try to hide it?

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: C├ędric VillemainDate: 2010-04-29 10:02:09
Subject: Re: Choosing between seqscan and bitmap scan
Previous:From: Heikki LinnakangasDate: 2010-04-29 09:38:46
Subject: Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-04-29 10:19:52
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Previous:From: Simon RiggsDate: 2010-04-29 08:18:57
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group