Re: max_worker_processes on the standby
От | Robert Haas |
---|---|
Тема | Re: max_worker_processes on the standby |
Дата | |
Msg-id | CA+TgmoZMbtM94LxedPFp9oHecRGkq-ReunYBnu+F_VkBW9m2OA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: max_worker_processes on the standby (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: max_worker_processes on the standby
|
Список | pgsql-docs |
On Thu, Jul 16, 2015 at 12:07 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > 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. Hmm, that seems like awfully weird behavior. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-docs по дате отправления: