From: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Michael Dungan <mpd(at)stipple(dot)com>, mcarey(at)stipple(dot)com |
Subject: | Re: [BUG] Streaming replica sees the old max_connections value |
Date: | 2014-03-07 21:04:20 |
Message-ID: | CAL_0b1vNQa952YWPVNybj8ib1dmUBZ=wZS-Hc3ZCoubwxUVCFg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Mar 7, 2014 at 12:22 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> LOG: database system is shut down
>> LOG: database system was shut down in recovery at 2014-03-07 19:00:49 GMT
>> LOG: entering standby mode
>> FATAL: hot standby is not possible because max_connections = 100 is a
>> lower setting than on the master server (its value was 500)
>> LOG: startup process (PID 12187) exited with exit code 1
>
> That's easy to explain. The check is done based on the control file and
> that's already on the standby in your case. You need to first replay a
> bit of WAL from the primary after lowering the value, triggering the
> standby to update what it knows about the master's settings. When
> lowering values, it's simplest to first restart the primary with the new
> values, wait for the standbys to catch up, and then restart them.
Thank you. It helped. Looks like 20 seconds of the delay between
restarts was not enough the first time.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray(dot)ru(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | mgerstein | 2014-03-07 21:07:10 | BUG #9478: Greenplum External Table definitions |
Previous Message | Andres Freund | 2014-03-07 20:22:16 | Re: [BUG] Streaming replica sees the old max_connections value |