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]>
Subject: Re: max_worker_processes on the standby
Date: Tue, 4 Aug 2015 17:35:47 -0400
Message-ID: <CA+TgmobyV2CAtMT6hRv8DkyRi61Dc6GysRnBjBJkTy1y=WEZ8g@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]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>
On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
<[email protected]> wrote:
> Robert Haas wrote:
>> On Thu, Jul 16, 2015 at 12:07 AM, Fujii Masao <[email protected]> wrote:
>> > One example which makes me a bit confusing is; both master and
>> > standby are running fine with track_commit_timestamp disabled,
>> > then I enable it only on the master. That is, the value of
>> > track_commit_timestamp is not the same between master and standby.
>> > No error happens in this case. According to the code of xlog_redo(),
>> > the commit timestamp tracking mechanism is activated in this case.
>
> Well. We could have the standby fail (i.e. stop replication) when it
> receives the WAL record indicating that the master turned it on. But
> that would be very unfriendly, so we chose to make it follow the
> master config instead. We're okay with this part, yes?
>
>> > However, after that, if standby is restarted, standby emits an error
>> > because the value of track_commit_timestamp is not the same between
>> > master and standby. Simple question is; why do we need to cause
>> > the standby fail in this case? Since I'm not familiar with the code of
>> > track_commit_timestamp yet, I'm not sure whether this behavior is
>> > valid or not.
>>
>> Hmm, that seems like awfully weird behavior.
>
> The alternative is to turn the feature on automatically if it sees that
> the master also has it on, i.e. the value would not be what the config
> file says it is. Doing this would be a bit surprising IMO, but given
> the behavior above maybe it's better than the current behavior.
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.
--
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]
Subject: Re: max_worker_processes on the standby
In-Reply-To: <CA+TgmobyV2CAtMT6hRv8DkyRi61Dc6GysRnBjBJkTy1y=WEZ8g@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