On 2015-08-05 00:13, Alvaro Herrera wrote:
Robert Haas wrote:
On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
<alvhe...@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).
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.
Actually, after thinking bit more about this I think the behavior of
these two will be similar - you suddenly lose the commit timestamp info.
The difference is that with fist option you'll lose it after restart
while with second one you lose it immediately after promotion since
there was never any info on the slave.
Extensions can do sanity checking in both scenarios.
The way I see it the first option has following advantages:
- it's smaller change
- it's more consistent with how wal_log_hints behaves
- fixing the config does not require server restart since the in-memory
state was set from WAL record automatically
However the second option has also some:
- one can have slave which doesn't have overhead of the commit timestamp
SLRU if they don't need it there
- it's theoretically easier to notice that the track_commit_timestamps
is off in config because the the SQL interface will complain if called
on the slave
So +0.5 from me towards following master and removing the error message
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
