On Sat, Mar 22, 2014 at 9:33 AM, Tatsuo Ishii <[email protected]> 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
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***************
*** 8904,8909 **** XLogReportParameters(void)
--- 8904,8910 ----
{
XLogRecData rdata;
xl_parameter_change xlrec;
+ XLogRecPtr recptr;
xlrec.MaxConnections = MaxConnections;
xlrec.max_worker_processes = max_worker_processes;
***************
*** 8917,8923 **** XLogReportParameters(void)
rdata.len = sizeof(xlrec);
rdata.next = NULL;
! XLogInsert(RM_XLOG_ID, XLOG_PARAMETER_CHANGE, &rdata);
}
ControlFile->MaxConnections = MaxConnections;
--- 8918,8925 ----
rdata.len = sizeof(xlrec);
rdata.next = NULL;
! recptr = XLogInsert(RM_XLOG_ID, XLOG_PARAMETER_CHANGE, &rdata);
! XLogFlush(recptr);
}
ControlFile->MaxConnections = MaxConnections;
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers