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

Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > I agree with your assessment for the most part, except for PGDATA.
> > There's no good reason I can think of for the postmaster to look at
> > it.
> 
> The other side of that coin is, what's the good reason to remove it?
> There's a long way between "I don't want my setup to depend on PGDATA"
> and "I don't think your setup should be allowed to depend on PGDATA".
> If you don't want to use it, then don't use it.  Why do you need to
> tell me how I'm allowed to run my installation?

I'm not talking about getting rid of ALL dependency on PGDATA in our
entire distribution, only postmaster's.

Recall that the main purpose of making any of these changes at all is
to make life easier for the guys who have to manage the systems that
will be running PostgreSQL.  Agreed?

So: imagine you're the newly-hired DBA and your boss points you to the
system and says "administrate the database on that".  You go over to
the computer and start looking around.

You do a "ps" and see a postmaster process running.  You know that
it's the process that is listening for connections.  The "ps" listing
only says "/usr/bin/postmaster".  No arguments to clue you in,
nothing.  Where do you look to figure out where the data is?  How do
you figure out what port it's listening on?

Well, we're already agreed on how to deal with that question: you look
in /etc/postgresql, and because this is a relatively new install (and
the PostgreSQL maintainers, who are very wise and benevolent, made
that the default location for configs :-), it has a postgresql.conf
file with a line that says "data_directory = /var/lib/pgsql".  It
doesn't mention a port to listen to so you know that it's listening on
port 5432.  As a DBA, you're all set.

Now let's repeat that scenario, except that instead of seeing one
postmaster process, you see five.  And they all say
"/usr/bin/postmaster" in the "ps" listing.  No arguments to clue you
in or anything, as before.  You might be able to figure out where one
of them is going by looking at /etc/postgresql, but what about the
rest?  Now you're stuck unless you want to do a "find" (time consuming
and I/O intensive -- a good way to slow the production database down a
bit), or you're knowledgeable enough to use 'lsof' or black magic like
digging into kernel memory to figure out where the config files and
data directories are, or you have enough knowledge to pore through the
startup scripts and understand what they're doing.

Lest you think that this is an unlikely scenario, keep in mind that
most startup scripts, including pg_ctl, currently start the postmaster
without arguments and rely on PGDATA, so a shop that hasn't already
been bitten by this *will* be.  Right now shops that wish to avoid the
trap I described have to go to *extra* lengths: they have to make
exactly the same kinds of changes to the scripts that I'm talking
about us making (putting an explicit '-D "$PGDATA"' where none now
exists) or they have to resort to tricks like renaming the postmaster
executable and creating a shell script in its place that will invoke
the (renamed) postmaster with '-D "$PGDATA"'.

It's not so bad if only a few shops have to make those changes.  But
what if it's thousands?  Yeah, the distribution guys can patch the
scripts to do this, but why should they have to?  They, and the shops
that run PostgreSQL, are our customers.


All of that is made possible because the postmaster can use an
inherited PGDATA for the location of the config files and (if the
config files don't say differently in our new scheme) the data
directory, and pg_ctl takes advantage of that fact (as do most startup
scripts that I've seen, that don't just invoke pg_ctl).

I'm not arguing that we should remove the use of PGDATA *everywhere*,
only in postmaster (and then, only postmaster's use of an *inherited*
PGDATA.  It should still set PGDATA so its children can use it).  It
means changing pg_ctl and the startup scripts we ship.  The earlier we
make these changes, the less overall pain there will be in the long
run.


> > ... people who are starting things by hand hopefully aren't so
> > inflexible as to demand that PGDATA remain treated as-is.
> 
> Yes, I could reconfigure my scripts to not depend on this.  You have
> not given me an adequate argument why I should have to.

[By this I'm assuming you're referring to the scripts you use for
testing, and not the ones that ship with the distribution]

I'm not arguing that you should get rid of all the references to
PGDATA in your scripts or anything crazy like that.  The changes I'm
talking about are minor: where you see "postmaster" without any "-D"
arguments, you simply add '-D "$PGDATA"' to it, before any other
arguments that you might also be passing.  That's it.  Nothing else
should be needed.

The reason for removing postmaster's use of an inherited PGDATA is the
same as the reason for making the other changes we already agree
should be made: to make things easier for the guys in the field who
have to manage production systems.



-- 
Kevin Brown                          kevin@sysexperts.com