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

> 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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to