Re: max_worker_processes on the standby

On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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