Re: [DOCS] max_worker_processes on the standby

[Fujii Masao]

On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas  wrote:
> On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera  
> wrote:
>>> I think it's totally reasonable for the standby to follow the master's
>>> behavior rather than the config file.  That should be documented, but
>>> otherwise, no problem.  If it were technologically possible for the
>>> standby to follow the config file rather than the master in all cases,
>>> that would be fine, too.  But the current behavior is somewhere in the
>>> middle, and that doesn't seem like a good plan.
>>
>> So I discussed this with Petr.  He points out that if we make the
>> standby follows the master, then the problem would be the misbehavior
>> that results once the standby is promoted: at that point the standby
>> would no longer "follow the master" and would start with the feature
>> turned off, which could be disastrous (depending on what are you using
>> the commit timestamps for).
>
> That seems like an imaginary problem.  If it's critical to have commit
> timestamps, don't turn them off on the standby.
>
>> To solve that problem, you could suggest that if we see the setting
>> turned on in pg_control then we should follow that instead of the config
>> file; but then the problem is that there's no way to turn the feature
>> off.  And things are real crazy by then.
>
> There's no existing precedent for a feature that lets the standby be
> different from the master *in any way*.  So I don't see why we should
> start here.  I think the reasonable definition is that the GUC
> controls whether the master tries to update the SLRU (and generate
> appropriate WAL records, presumably).  The standby should not get a
> choice about whether to replay those WAL records.

+1

I added this to the 9.5 open item list.

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

Re: [DOCS] max_worker_processes on the standby

[Fujii Masao]

On Thu, Jul 16, 2015 at 1:07 PM, Fujii Masao  wrote:
> On Wed, Jul 15, 2015 at 5:57 PM, Alvaro Herrera
>  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