Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > I assume $PGDATA was around long before GUC? > > Yes, it was. But I have not yet seen an argument here that justifies > why $SOMECONFIGDIRECTORY/postgresql.conf is better than > $PGDATA/postgresql.conf.
Okay, here's one: most Unix systems store all of the configuration files in a well known directory: /etc. These days it's a hierarchy of directories with /etc as the root of the hierarchy. When an administrator is looking for configuration files, the first place he's going to look is in /etc and its subdirectories. After that, he's forced to look through the startup scripts to figure out where things are located. And if those aren't revealing, then he has to read manpages and hope they're actually useful. :-) And if that doesn't work, then he has to resort to tricks like doing "strings" on the binaries (he doesn't necessarily have access to the sources that the binaries were compiled from, which is all that matters here). > The latter keeps all the related files together. The former seems > only to introduce unnecessary complexity. Well, I'd say it's "unnecessary" only when you already know where the data files are located -- which is true when you're a developer or someone who is already familiar with the installation you're working with. But if you're just getting started and installed it from a package like an RPM file, then you have to look in the package to see where it created the data file areas, or look at the startup scripts, etc. > You can only justify it as simpler if you propose hardwiring a value > for $SOMECONFIGDIRECTORY ... Making things simpler from the standpoint of the code isn't the point. Making things simpler for the DBA and/or Unix sysadmin is. I'd say $SOMECONFIGDIRECTORY should be a hardwired default with a command line override. I doubt you'll get a whole lot of argument from the general user community if you say that the hard wired default should be /etc/postgresql. > which is a proposal that will not fly with any of the core > developers, because we all run multiple versions of Postgres on our > machines so that we can deal with back-version bug reports, test > installations, etc. I absolutely agree that the config directory to use should be something that can be controlled with a command line option. > It is unlikely to fly with any of the RPM packagers either, due to > the wildly varying ideas out there about the One True Place where > applications should put their config files. There seems to be substantial agreement among the distribution maintainers that config files belong somewhere in /etc. At least, I've seen very little disagreement with that idea except from people who believe that each package should have its own, separate directory hierarchy. And the fact that the vast majority of packages put their config files somewhere in /etc supports this. Debian, for instance, actually *does* put the PostgreSQL config files in /etc/postgresql and creates symlinks in the data directory that point to them. This works, but it's a kludge. There are highly practical reasons for putting all the config files under /etc, not the least of which is that it makes backing up files that are *very* likely to change from the default, and which are also highly critical to the operation of the system, very easy. You'll get A LOT more disagreement about where to put data files than config files, as standards go. And in the case of PostgreSQL, where you put your data files is especially important for performance reasons, so it therefore makes even less sense to put the config files in the same location: it means that the config files could literally be anywhere, and any administrator who is unfamiliar with the system will have to dig through startup scripts (or worse!) to figure it out. Oh, here's another reason $SOMECONFIGDIRECTORY is better than $PGDATA: it allows much more appropriate separation of concern by default. Most installations of PostgreSQL start the database from a startup script that's run at boot time. With $PGDATA, changing the target data directory requires changing the startup script, which requires root access to the system -- if it didn't require root access then the entire system is open to the possibility of a world of hurt because the DBA isn't necessarily the same guy as the Unix sysadmin and therefore doesn't necessarily know his way around shell scripts in general, and rc scripts in particular, the way the Unix admin will. The possibility of hurt comes from the fact that the rc script runs at root, at a time that the system is hardest to work with in the event of a failure (many systems haven't even put up any console login prompts and may not have even started any remote login facilities before the PostgreSQL startup script runs). A sufficiently bad screwup on the part of the DBA with that kind of setup will require the Unix sysadmin to go to single user mode or worse to fix it. So unless the Unix sysadmin really trusts the DBA, he's not going to allow the DBA that kind of access. Instead he'll kludge something together so that the DBA can make the appropriate kinds of changes without compromising the system. But every shop will do this a different way. Even Debian, which usually is pretty good about dealing with issues like these, doesn't address this. But it shouldn't even be necessary for a shop to kludge around the problem: with $SOMECONFIGDIRECTORY, the Unix sysadmin can safely give write permissions to the DBA on the config files (and even on the entire directory they reside in), the DBA can point the database at whatever directory he wants the data to reside in, and the Unix admin only has to set up the storage areas, set the permissions, and let the DBA loose on it -- he doesn't have to touch the startup scripts at all, the DBA doesn't have to be much of a shell script wizard, and everyone is (relatively) happy. And, even better, the DBA will be able to do this at most shops he works for because his knowledge will be based on the standard PostgreSQL install. If we want to get wider acceptance amongst the heavy database users (which often *do* separate DBAs from Unix sysadmins), we may want to think about things like this from time to time... -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
