MIME-Version: 1.0
Date: Thu, 3 Sep 2015 22:03:44 +0900
Message-ID: 
 <CAHGQGwE5gw63zY8+jfaF++AKxk8nS21eHREjCCYOB=sdJLROwQ@mail.gmail.com>
Subject: Re: max_worker_processes on the standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 pgsql-docs <pgsql-docs@postgresql.org>,
 Pg Hackers <pgsql-hackers@postgresql.org>,
 =?UTF-8?Q?Petr_Jel=C3=ADnek?= <petr@2ndquadrant.com>,
 Craig Ringer <craig@2ndquadrant.com>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

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


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