On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Thu, Jul 16, 2015 at 12:07 AM, Fujii Masao <masao.fujii@gmail.com> 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