On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: >>> 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). > > That seems like an imaginary problem. If it's critical to have commit > timestamps, don't turn them off on the standby. > >> 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. > > There's no existing precedent for a feature that lets the standby be > different from the master *in any way*. So I don't see why we should > start here. I think the reasonable definition is that the GUC > controls whether the master tries to update the SLRU (and generate > appropriate WAL records, presumably). The standby should not get a > choice about whether to replay those WAL records.
+1 I added this to the 9.5 open item list. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
