RH, Simon, > I think that might have some possibilities. But how does that work in > detail? If you set it to empty, then the recovery_* parameters are > just GUCs, I suppose: which seems fine. But if you set it to a > non-empty value then what happens, exactly? The recovery.conf > settings clobber anything in postgresql.conf, and when we exit > recovery we reload the config, discarding any settings we got from > recovery.conf? That might not be too bad.
Yeah, that's what I was picturing. By tying backwards-compatibility to a setting in pg.conf, you eliminate a lot of changes for a DBA accidentally enabling it. This also then supports re-locating the recovery.conf file, which has been an issue for a long time. > I think we need to back up and figure out what problem we're trying to > solve here. IMV, the answer is "setting up a standby is too > complicated and requiring yet another configuration file to do it > makes it even more complicated". If the mechanism we introduce to > "solve" that problem is more complicated than what we have now, it > might end up being a net regression in terms of usability. Well, as someone who sets up and admins replication for a bunch of clients, here's what I'd like to see: 1. no more using a configuration file as a trigger 2. ability to put replication configuration in postgresql.conf or in a manually designated include file 3. having replication configuration show up in pg_settings The three settings above would make my life as a contract DBA much easier ... and I presume help a lot of our users like me. Among other things, fixing the 3 things above would make replication integrate a lot better with configuration management systems and monitoring. > I feel like changing everything that's currently in recovery.conf to > GUCs and implementing SET PERSISTENT would give everyone what they > need, admittedly without perfect backward compatibility, but perhaps > close enough for government work, and a step forward overall. Is anyone working on SET PERSISTENT? I thought that got bike-shedded to death. > So backwards compatibility is important for downstream software. > If it wasn't, we wouldn't be having this discussion. However, backwards compatibility is not necessarily the *most* important consideration. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
