MIME-Version: 1.0
In-Reply-To: 
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
References: 
 <CAHGQGwE48ViDkwybpxjXuf-trC87Ar1jdCHZ+ogtduoo3uvB8w@mail.gmail.com>
 <20150715085751.GD2301@postgresql.org>
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
Date: Thu, 3 Sep 2015 22:33:30 +0900
Message-ID: 
 <CAHGQGwFTPQ9jfG2Sehguaiji13HXz2UA6S-LNAyDYQCcxF3CLA@mail.gmail.com>
Subject: Re: max_worker_processes on the standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-docs <pgsql-docs@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

On Thu, Jul 16, 2015 at 1:07 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> 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?

Applied the patch.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs