On 17.9.2012 16.57, Fujii Masao wrote: > On Tue, Sep 18, 2012 at 3:51 AM, <pet...@petteriraty.eu> wrote: >> The following bug has been logged on the website: >> >> Bug reference: 7549 >> Logged by: Petteri Räty >> Email address: pet...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
