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