public inbox for [email protected]  

help / color / mirror / Atom feed

From: Fujii Masao <[email protected]>
To: Robert Haas <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: pgsql-docs <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Petr Jelínek <[email protected]>
Cc: Craig Ringer <[email protected]>
Subject: Re: max_worker_processes on the standby
Date: Thu, 3 Sep 2015 22:03:44 +0900
Message-ID: <CAHGQGwE5gw63zY8+jfaF++AKxk8nS21eHREjCCYOB=sdJLROwQ@mail.gmail.com> (raw)
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas <[email protected]> wrote:
> On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

view thread (38+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: max_worker_processes on the standby
  In-Reply-To: <CAHGQGwE5gw63zY8+jfaF++AKxk8nS21eHREjCCYOB=sdJLROwQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox