public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Fujii Masao <[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: Sat, 8 Aug 2015 10:02:38 -0400
Message-ID: <CA+TgmoZjXJZZL4GYvamFZZYnO6H9d8oST1b2y=rDaYHdWS1c4Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAHGQGwE48ViDkwybpxjXuf-trC87Ar1jdCHZ+ogtduoo3uvB8w@mail.gmail.com>
<[email protected]>
<CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
<CA+TgmoZMbtM94LxedPFp9oHecRGkq-ReunYBnu+F_VkBW9m2OA@mail.gmail.com>
<[email protected]>
<CA+TgmobyV2CAtMT6hRv8DkyRi61Dc6GysRnBjBJkTy1y=WEZ8g@mail.gmail.com>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>
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.
Note that if you do allow the standby to decide not to replay the WAL
records for this feature, then the data on the standby could be
partially there but not completely there after promotion, because the
DBA might have flipped the switch on and off at different times.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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: <CA+TgmoZjXJZZL4GYvamFZZYnO6H9d8oST1b2y=rDaYHdWS1c4Q@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