Re: Standby server won't start
От | Fujii Masao |
---|---|
Тема | Re: Standby server won't start |
Дата | |
Msg-id | CAHGQGwHNM32xmfUNwTGV2nf4-p-PrZX-OVmjxgLL9vkSFBZ1YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Standby server won't start (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: