Re: location of the configuration files

Tom Lane wrote:
> Kevin Brown <kevin(at)sysexperts(dot)com> 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 kevin(at)sysexperts(dot)com