Re: [DOCS] max_worker_processes on the standby
От | Petr Jelinek |
---|---|
Тема | Re: [DOCS] max_worker_processes on the standby |
Дата | |
Msg-id | 5622BF9D.2010409@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [DOCS] max_worker_processes on the standby (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [DOCS] max_worker_processes on the standby
|
Список | pgsql-hackers |
On 2015-10-02 22:02, Robert Haas wrote: > On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Robert Haas wrote: >>> The standby can have the feature enabled even though the master has it >>> disabled? That seems like it can only lead to heartache. >> >> Can you elaborate? > > Sort of. Our rule up until now has always been that the standby is an > exact copy of the master. I suspect deviating from that behavior will > introduce bugs. I suspect having the standby make data changes that > aren't WAL-logged will introduce bugs; not to be unkind, but that > certainly seems like a lesson to take from what happened with > multixacts. > I agree with that sentiment. Attached patch adds variable to the shmem which is used for module activation tracking - set to true in ActiveCommitTs() and false in DeactivateCommitTs(). All the checks inside the commit_ts code were changed to use this new variable. I also removed the static variable Alvaro added in previous commit because it's not needed anymore. The patch also does full cleanup of the shmem state in DeactivateCommitTs() so that standby does not have stale last committed transaction info after enable/disable/enable cycle on primary I also removed no longer used do_wal parameters in couple of functions. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: