Re: location of the configuration files
От | Tom Lane |
---|---|
Тема | Re: location of the configuration files |
Дата | |
Msg-id | 3825.1045195202@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: location of the configuration files (Lamar Owen <lamar.owen@wgcr.org>) |
Ответы |
Re: location of the configuration files
(Kevin Brown <kevin@sysexperts.com>)
Re: location of the configuration files (Bruce Momjian <pgman@candle.pha.pa.us>) Re: location of the configuration files (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Lamar Owen <lamar.owen@wgcr.org> writes: > Ok, if we're going this far already, tell me exactly why we have three config > files. Why not really Unify things and fulfil the full promise of Grand > Unified Configuration by rolling hba and ident into postgresql.conf. Is > there a compelling reason not to do so? Lack of backwards compatibility; unnecessary complexity. Unifying those files would create a big headache in terms of having to unify their syntax. And there are some basic semantic differences too. For instance, order matters in pg_hba.conf, but not in postgresql.conf. Another reason not to do it is that there are differences in the security requirements of these files. postgresql.conf probably doesn't contain anything that needs to be hidden from prying eyes, but I'd be inclined to want to keep the other two mode 600. --- Okay, I've been laying low all day, but here are my thoughts on the discussion: I do see the value in being able to (as opposed to being forced to, please) keep hand-edited config files in a separate location from the machine-processed data files. We have already gone some distance in that direction over the past few releases --- there's much less in the top $PGDATA directory than there once was. It makes sense to let people keep hand-edited files away from what initdb will overwrite. I would favor a setup that allows a -C *directory* (not file) to be specified as a postmaster parameter separately from the -D directory; then the hand-editable config files would be sought in -C not -D. In the absence of -C the config files should be sought in -D, same as they ever were (thus simplifying life for people like me who run many postmasters and don't give a darn about FHS ;-)). I don't see any great value in a separate postgresql.conf parameter for each secondary config file; that just means clutter to me, especially if we add more such files in future. I am also distinctly not in favor of eliminating the PGDATA environment variable; that reads to me as "we are going to force you to do it our way rather than the way you've always done it, even if you like the old way". To make the RPM packagers happy, I guess that the default -C directory has to be settable via configure. We do not currently have a default -D directory, and I didn't hear anyone arguing in favor of adding one. So that leaves the following possible combinations that the postmaster might see at startup, for which I propose the following behaviors: 1. No -C switch, no -D switch, no PGDATA found in environment: seek postgresql.conf in the default -C directory established at configure time. Use the 'datadir' specified therein as -D. Fail if postgresql.conf doesn't define a datadir value. 2. No -C switch, no -D switch, PGDATA found in environment: use $PGDATA as both -C and -D. (Minor detail: if the postgresql.conf in the $PGDATA directory specifies a different directory as datadir, do we follow that or raise an error? I'd be inclined to say "follow it" but maybe there is an argument for erroring out.) (In all the following cases, any environment PGDATA value is ignored.) 3. No -C switch, -D switch on command line: use -D value as both -C and -D, proceed as in case 2. 4. -C switch, no -D switch on command line: seek postgresql.conf in -C directory, use the datadir it specifies. 5. -C and -D on command line: seek postgresql.conf in -C directory, use -D as datadir overriding what is in postgresql.conf (this is just the usual rule that command line switches override postgresql.conf). Cases 2 and 3 are backwards-compatible with our historical behavior, so that anyone who likes the historical behavior will not be unhappy. Cases 1 and 4 I think will make mlw and our packagers happy. Case 5 is just the logical conclusion for that combination. In all cases, pg_hba.conf and pg_ident.conf would be sought in the same directory as postgresql.conf. The other stuff in the toplevel $PGDATA directory should stay where it is, IMHO. I would venture that the configure-time-default for -C should be ${prefixdir}/etc if configure is not told differently, while the packagers would probably set it to /etc/postgresql/ (ie, the config files should live in a subdirectory that can be owned by postgres user). I'm not wedded to that though. Another interesting question is whether the installed-by-default postgresql.conf should specify a datadir value, and if so what. If initdb installs it, it can and probably should insert the actual datadir location the user gave to initdb into the file. But should initdb install any config files at all anymore? I'm leaning to the thought that initdb should store default config files into $PGDATA same as it ever did, and then it's up to the user (or package install scripts) to move them to the desired -C directory if appropriate. Or I suppose we could add a -C parameter to initdb to tell it where to put 'em. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: