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.
Regards,
--
Fujii Masao
