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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
