Re: location of the configuration files - Mailing list pgsql-hackers

<br /><br /> Stephan Szabo wrote:<br /><blockquote cite="mid20030213114014.S47380-100000@megazone23.bigpanda.com"
type="cite"><prewrap="">On Thu, 13 Feb 2003, mlw wrote:
 
 </pre><blockquote type="cite"><pre wrap="">Stephan Szabo wrote:   </pre><blockquote type="cite"><blockquote
type="cite"><blockquotetype="cite"><pre wrap="">On Thu, 2003-02-13 at 09:23, mlw wrote:         </pre><blockquote
type="cite"><prewrap="">I deal with a number of PG databases on a number of sites, and it is a
 
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's really
annoying is when you have to find the data directory when someone else
set up the system.

           </pre></blockquote></blockquote></blockquote><pre wrap="">You realize that the actual code feature doesn't
necessarilyhelp this
 
case, right? Putting configuration in /etc and having a configuration file
option on the command line are separate concepts.     </pre></blockquote></blockquote><pre wrap="">
Re-read my statement and yours about the case you were mentioning. ;)
Sure, putting the files in /etc lets you find them easily.  However, if
you're doing things like finding configuration made by someone else and
said configuration isn't in /etc (which if they wanted to they could do
now with symlinks I believe - yes symlinks aren't a complete solution, but
I think they're reasonable on most of our current ports) then you still
have to search the system for the configuration file, except now it might
not even be postgresql.conf. That's why I said the two issues aren't the
same.
 </pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">I think the feature is worthwhile, but I have some
initialcondition
 
functionality questions that may have been answered in the previous patch,
but I don't remember at this point.

Mostly these have to deal with initial creation.  Does the user specify an
output location to initdb, do they just specify a data dir as now where
the configuration goes but then they need to move it somewhere, does
initdb now do nothing relating to configuration file and the user should
make one on his own.  Related, is the admin expected to have already made
(say) /etc/postgresql to stick the config in and set the permissions
correctly (since initdb doesn't run as root)?
     </pre></blockquote><pre wrap="">My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.

The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/etc/postgres/pg_ident.conf'
datadir='/RAID0/postgres'

The command line option is a capital 'C,' as in:
postmaster -C /etc/postgresql.conf

I have no problem leaving the default configuration files remaining in
the data directory as sort of a maintenance / boot strap sort of thing,
so I don't see any reason to alter the installation.


As for this feature helping or not, I think it will. I think it
accomplishes two things:
(1) Separates configuration from data.
(2) Allows an administrator to create a convention across multiple
systems regardless of the location and mount points of the database storage.
(3) Lastly, it is a familiar methodology to DBAs not familiar with
PostgreSQL.   </pre></blockquote><pre wrap="">
I agree on all these points ("I think the feature is worthwhile, but...").
I just wonder if we were going to do this, we might as well look at all of
the various things people want and decide what we want to do, for example,
people commenting on default configuration locations through configure,
how does this interact with what we have now, etc.  I'd rather have a
month spent arguing out a behavior rather than just adding a new behavior
that we'll need to possibly revisit again in the future. :)</pre></blockquote><br /> I have absolutely no problem
debatingand augmenting the feature. None what so ever, I am more pushing to get momentum to actually do it. In 7.1 I
proposedthis, and was told that it wasn't needed because (a) symlinks provide all the functionality you need and (b)
thatthey were going to redesign the configuration system. That was well over a year ago (two?). I am willing to do the
work,but what's the point if the core group isn't even going to use it?<br /><br /> Most of the admins I know don't use
symlinksas they can not carry comments. Without knowing,  you can change or delete a file that does not appear to be in
usebut which kills a working server. Symlinks are dangerous in production systems, it is easy to screw them up with scp
whenadministering a cluster of computers.<br /><br /><br /><blockquote
cite="mid20030213114014.S47380-100000@megazone23.bigpanda.com"type="cite"><pre wrap=""> </pre></blockquote>