On Wed, Jun 1, 2011 at 5:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@agliodbs.com> writes: >> pg_ctl -D means different things depending on whether you are calling >> "start" or "stop". For "start", pg_ctl wants the directory >> postgresql.conf is in, and for "stop" it wants the directory >> postmaster.pid is in. This means that if your .conf files are not in >> the same directory as data_directory, you have to write special-case >> code for start and stop. > > Well, the entire business of allowing the config files to be outside the > data directory is bad design/poor UI. It's not pg_ctl that's the main > problem here. > >> Given that having the .conf files in /etc is the default configuration >> for both Red Hat and Debian, this seems like really poor UI design on >> our part. > > I can't speak for Debian, but the above statement is 100% false for Red > Hat. In any case, no RH system has ever expected users to issue pg_ctl > start/stop directly, and I think the same is true for Debian, so the > bizarre design wouldn't matter to us even if the case did apply. > >> It actually seems relatively easy to fix this without breaking >> backwards-compatibility. > > No, it isn't. You're making way too many assumptions about where things > really were and what arguments were given to pg_ctl start. We went > around on this before, which is why it's not "fixed" already.
ISTM that it would be useful to run postgres in a mode where it doesn't actually try to start up the database, but parses postgresql.conf and then exits, perhaps printing out the value of a certain GUC as it does so. In this case, data_directory. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
