Thread: BUG #7549: max_connections check should query master when starting standby
BUG #7549: max_connections check should query master when starting standby
From
petsku@petteriraty.eu
Date:
The following bug has been logged on the website: Bug reference: 7549 Logged by: Petteri R=C3=A4ty 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 =3D 20 is a low= er 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=3D# 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. Regards, Petteri
Re: BUG #7549: max_connections check should query master when starting standby
From
Fujii Masao
Date:
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=E4ty > 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 a= nd > you might need to choose an earlier recovery target. > LOG: entering standby mode > FATAL: hot standby is not possible because max_connections =3D 20 is a l= ower > 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 resol= ve > it I lowered the setting on the master: > > postgres=3D# SHOW max_connections; > max_connections > ----------------- > 20 > (1 row) > > The slave should allow resolving the issue by not only changes on the sla= ve > 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, --=20 Fujii Masao
Re: BUG #7549: max_connections check should query master when starting standby
From
Petteri Räty
Date:
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
Re: BUG #7549: max_connections check should query master when starting standby
From
Craig Ringer
Date:
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
Re: BUG #7549: max_connections check should query master when starting standby
From
Heikki Linnakangas
Date:
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
Re: BUG #7549: max_connections check should query master when starting standby
From
Fujii Masao
Date:
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
Re: BUG #7549: max_connections check should query master when starting standby
From
Bruce Momjian
Date:
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. +