Re: max_worker_processes on the standby
От | Fujii Masao |
---|---|
Тема | Re: max_worker_processes on the standby |
Дата | |
Msg-id | CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: max_worker_processes on the standby (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: max_worker_processes on the standby
Re: max_worker_processes on the standby Re: max_worker_processes on the standby |
Список | pgsql-docs |
On Wed, Jul 15, 2015 at 5:57 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Fujii Masao wrote: >> Hi, >> >> "25.5.3. Administrator's Overview" in the document >> ----------------------------------------------------- >> The setting of some parameters on the standby will need reconfiguration >> if they have been changed on the primary. For these parameters, >> the value on the standby must be equal to or greater than the value >> on the primary. If these parameters are not set high enough then >> the standby will refuse to start. Higher values can then be supplied >> and the server restarted to begin recovery again. These parameters are: >> max_connections >> max_prepared_transactions >> max_locks_per_transaction >> ----------------------------------------------------- >> >> I found that the value of max_worker_processes on the standby also >> must be equal to or greater than the value on the master. So we should >> just add max_worker_processes to this paragraph. Patch attached. > > True. Also track_commit_timestamp. Yes, but I intentionally did not include track_commit_timestamp in the patch because it's not easy for me to document the hot standby condition of track_commit_timestamp unless I read the code more. One example which makes me a bit confusing is; both master and standby are running fine with track_commit_timestamp disabled, then I enable it only on the master. That is, the value of track_commit_timestamp is not the same between master and standby. No error happens in this case. According to the code of xlog_redo(), the commit timestamp tracking mechanism is activated in this case. However, after that, if standby is restarted, standby emits an error because the value of track_commit_timestamp is not the same between master and standby. Simple question is; why do we need to cause the standby fail in this case? Since I'm not familiar with the code of track_commit_timestamp yet, I'm not sure whether this behavior is valid or not. > Can you add a comment somewhere in > CheckRequiredParameterValues(void) that the set of parameters is listed > in section such-and-such in the docs, so that next time there's a higher > chance that the docs are kept up to date? +1 What about the attached patch? Regards, -- Fujii Masao
Вложения
В списке pgsql-docs по дате отправления: