BUG #7549: max_connections check should query master when starting standby

On Tue, Sep 18, 2012 at 3:51 AM, <petsku@petteriraty.eu> wrote:

The following bug has been logged on the website:

Bug reference: 7549
Logged by: Petteri Räty
Email address: petsku@petteriraty.eu
PostgreSQL version: 9.2.0
Operating system: Linux or OS X
Description:

On a streaming hot standby slave starting postgres:

LOG: database system was interrupted while in recovery at log time
2012-09-17 21:29:31 EEST
HINT: If this has occurred more than once some data might be corrupted and
you might need to choose an earlier recovery target.
LOG: entering standby mode
FATAL: hot standby is not possible because max_connections = 20 is a lower
setting than on the master server (its value was 100)
LOG: startup process (PID 51494) exited with exit code 1
LOG: aborting startup due to startup process failure

It was indeed the case that the limit was lower on the slave but to resolve
it I lowered the setting on the master:

postgres=# SHOW max_connections;
max_connections
-----------------
20
(1 row)

The slave should allow resolving the issue by not only changes on the slave
side but by checking if the master has been updated as well.

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

Regards,

--
Fujii Masao

On 17.9.2012 16.57, Fujii Masao wrote:

On Tue, Sep 18, 2012 at 3:51 AM, <petsku@petteriraty.eu> wrote:

The following bug has been logged on the website:

Bug reference: 7549
Logged by: Petteri Räty
Email address: petsku@petteriraty.eu
PostgreSQL version: 9.2.0
Operating system: Linux or OS X
Description:

On a streaming hot standby slave starting postgres:

LOG: database system was interrupted while in recovery at log time
2012-09-17 21:29:31 EEST
HINT: If this has occurred more than once some data might be corrupted and
you might need to choose an earlier recovery target.
LOG: entering standby mode
FATAL: hot standby is not possible because max_connections = 20 is a lower
setting than on the master server (its value was 100)
LOG: startup process (PID 51494) exited with exit code 1
LOG: aborting startup due to startup process failure

It was indeed the case that the limit was lower on the slave but to resolve
it I lowered the setting on the master:

postgres=# SHOW max_connections;
max_connections
-----------------
20
(1 row)

The slave should allow resolving the issue by not only changes on the slave
side but by checking if the master has been updated as well.

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

Regards,

If that's the case then would make sense to document it in connection to
the output. I wouldn't have guessed that to be the case.

Regards,
Petteri

On 09/18/2012 07:57 AM, Fujii Masao wrote:

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

WTF, really?

What else breaks the replication and forces a re-clone?

--
Craig Ringer

On 18.09.2012 09:46, Craig Ringer wrote:

On 09/18/2012 07:57 AM, Fujii Masao wrote:

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

WTF, really?

No. It's enough to bump up max_connections on the standby, and restart.

- Heikki

On Mon, Sep 17, 2012 at 11:46 PM, Craig Ringer <ringerc@ringerc.id.au>wrote:

On 09/18/2012 07:57 AM, Fujii Masao wrote:

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

WTF, really?

What else breaks the replication and forces a re-clone?

Another WTF from me too.

I can understand moving from read-only to read-write, but internally *why*
does this happen? If it is the case, it needs to be clearly documented.

(mental note to test this and report back).

Why would this create a different timeline?

Best Wishes,
Chris Travers

On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:

On 18.09.2012 09:46, Craig Ringer wrote:

On 09/18/2012 07:57 AM, Fujii Masao wrote:

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

WTF, really?

No. It's enough to bump up max_connections on the standby, and restart.

Hmm... Petteri wants to solve the issue without changing anything
on the standby, according to his original post. So in his case, a fresh
backup is required.

Of course my previous answer was confusing...

Regards,

--
Fujii Masao

On Tue, Sep 18, 2012 at 09:09:13PM +0900, Fujii Masao wrote:

On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:

On 18.09.2012 09:46, Craig Ringer wrote:

On 09/18/2012 07:57 AM, Fujii Masao wrote:

If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.

WTF, really?

No. It's enough to bump up max_connections on the standby, and restart.

Hmm... Petteri wants to solve the issue without changing anything
on the standby, according to his original post. So in his case, a fresh
backup is required.

Of course my previous answer was confusing...

I assume you mean the slave needs an updated copy of the master's
config file changes, not an entire copy of the data directory.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +