On Thu, 14 Aug 2008, Andrew Satori wrote:
What I'm seeing is a default installation protects the Data directory properly, but in so doing means that altering the configuration files, pg_hba.conf and postgresql.conf require database administrators, who should not necessarily have a level of rights to become superuser at the file system level to alter the mentioned files.
This suggests you're doing something wrong, and it's no wonder you think this is a serious management problem (I consider it a minor one).
In a typical installation, the data directory that contains the database and configuring files will be owned by a database user, typically "postgres". DBAs should be able to get to all of those by switching to that user, without need any true superuser rights. If that isn't the case in your environment, I'm curious how you ended up there, and it's no wonder that's a serious management problem for you. I consider this area only a minor annoyance. Normally the only thing I see that you can't do as the postgres user is directly execute the database start/stop scripts that root runs ("service postgresql start" on RedHat for example), but since all that can be done via pg_ctl instead this is an easily scriptable issue to work around.
A huge portion of the motivation here is to allow for easy to graphical administration interfaces, making the system more approachable, and to make remote administration of these files less cumbersome.
There's already a bunch of work in that area going on already. Check the archives for the "GUCS Overhaul" and "Parsing of pg_hba.conf and authentication inconsistencies" threads for two long-running discussions of the fundamental server-side issues needed to pull that off. You touched on the main one here:
Since most changes would require a SIGHUP, should the server process itself be alter to allow for a dynamic restart from within the environment?
Many of the problems with what you're thinking of revolve around the unfortunate answers that pop up when you ask "what if I try and put bad information in postgresql.conf/pg_hba.conf?"; see those threads I mentioned for some context on that.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
