Re: max_worker_processes on the standby
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-docs <pgsql-docs@postgresql.org>
Date: 2015-07-16T04:07:50Z
Lists: pgsql-hackers, pgsql-docs
Attachments
- doc_v2.patch (text/x-patch) patch v2
- (unnamed) (text/plain)
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
Commits
-
Cleanup commit timestamp module activaction, again
- 68cc162e454a 9.5.0 landed
- 531d21b75ff6 9.6.0 landed
-
Code review for transaction commit timestamps
- 6b61955135e9 9.6.0 cited