From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: max_worker_processes on the standby |
Date: | 2015-07-16 04:07:50 |
Message-ID: | CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Wed, Jul 15, 2015 at 5:57 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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
Attachment | Content-Type | Size |
---|---|---|
doc_v2.patch | text/x-patch | 985 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | 김기성 | 2015-07-16 04:18:50 | Publishing PG docs |
Previous Message | Alvaro Herrera | 2015-07-15 08:57:52 | Re: max_worker_processes on the standby |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-07-16 04:21:36 | option for psql - short list non template database |
Previous Message | Amit Kapila | 2015-07-16 03:59:10 | Re: [DESIGN] Incremental checksums |