Re: [BUG] Streaming replica sees the old max_connections value

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

In response to

Browse pgsql-bugs by date

  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