From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelínek <petr(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: max_worker_processes on the standby |
Date: | 2015-09-03 13:03:44 |
Message-ID: | CAHGQGwE5gw63zY8+jfaF++AKxk8nS21eHREjCCYOB=sdJLROwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2015-09-03 13:33:30 | Re: max_worker_processes on the standby |
Previous Message | Bruce Momjian | 2015-09-02 01:15:16 | Re: Wrong Typo |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2015-09-03 13:04:01 | Re: WIP: Make timestamptz_out less slow. |
Previous Message | Stephen Frost | 2015-09-03 12:53:20 | Re: Allow replication roles to use file access functions |