On Mon, Mar 24, 2014 at 8:59 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Sat, Mar 22, 2014 at 9:33 AM, Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
