Adding CC to hackers, since this is clearly not just a docs issue. Also
CCing Petr and Craig since they are the ones that know how this is used
in BDR.
Robert Haas wrote:
> On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > 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.
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).
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.
Given this, we're leaning towards the idea that the standby should not
try to follow the master at all. Instead, an extension that wants to
use this stuff can check the value for itself, and raise a fatal error
if it's not already turned on the config file. That way, a lot of the
strange corner cases disappear.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services