On Mon, Mar 24, 2014 at 8:59 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sat, Mar 22, 2014 at 9:33 AM, Tatsuo Ishii <ishii@postgresql.org> wrote:
>>> That's because the parameter is checked at the beginning of recovery
>>> (i.e. at standby start) before XLOG_PARAMETER_CHANGE is received and
>>> applied on the standby. Please see CheckRequiredParameterValues() in
>>> StartupXLOG().
>>>
>>> To persist the max_connections change:
>>>
>>> 1) stop primary
>>> 2) change max_connections on the primary
>>> 3) start primary
>>> 4) watch pg_stat_replication to wait until the standby is sync with
>>> the primary (XLOG_PARAMETER_CHANGE is applied)
>>> 5) stop standby
>>> 6) change max_connections on the standby
>>> 7) start standby
>>
>> Unfotunately this did not work for me. pg_stat_replication showed
>> replay_location and sent_location are identical, and I assume the
>> standby is sync with the primary in step #4. Still the standby did not
>> start in #7 with same error message I showed. This is PostgreSQL
>> 9.3.3. Also pg_controldata <standby DB cluster> showed the old
>> max_connections at #7. So I guess XLOG_PARAMETER_CHANGE has not been
>> sent for some reason. Will look into this.
>
> ISTM that's because WAL has not been flushed after XLOG_PARAMETER_CHANGE
> is generated. Attached patch fixes this problem.
Committed.
Regards,
--
Fujii Masao