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
