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
