Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > The goal here is simply to make it obvious to a system administrator where
> > the PG data directory that a given postmaster is using resides.
>
> Why would it not be sufficient to add a read-only GUC variable that
> tells that? Connect to the postmaster and do "show datadir" and you're
> done. (Without this, it's not clear you've made any particular gain
> anyway, since "a given postmaster" would typically mean "the one I can
> connect to at this port", no?)
That would probably be sufficient for most cases. It wouldn't take care
of the case where there's a strict separation of powers between the
system administrator and the DBA, but only if the system were managed
badly (i.e., the SA and the DBA don't talk to each other very well).
That's probably something we shouldn't concern ourselves with.
> In any case I don't see how removing PGDATA would make this more
> obvious. You yourself just pointed out that the command-line arguments
> of a postmaster aren't necessarily visible through ps; if they're not,
> what have you gained in transparency by forbidding PGDATA?
I think you misunderstood what I was saying (which means I didn't say it
right).
There are ways within a program to change what 'ps' shows as the
command line. We use those methods to make it possible to see what
a given backend is doing by looking at the 'ps' output. It would be
possible to have the postmaster use those ways in order to show which data
directory it is using even if it wasn't specified on the command line.
But in my experience, those ways don't work reliably on all systems.
On the systems that those methods don't work, what 'ps' shows is the
original command line that was used. So clearly, the only way 'ps'
will show the data directory in that instance is if it was actually
specified on the command line.
> > In any case, I'm not at all opposed to having the backend stuff know
> > about PGDATA during development, but for production you should have to
> > explicitly specify the data directory on the command line.
>
> If you wish to do things that way, you can; but that doesn't mean that
> everyone else should have to do it that way too. If there were a
> security or reliability hazard involved, I might agree with taking the
> fascist approach, but I see no such hazard here ...
Fair enough. The PGDATA issue isn't a big enough one that I'm terribly
concerned about it, especially if a read-only GUC variable is available
to give that information (something that, I think, should be there
anyway).
--
Kevin Brown kevin@sysexperts.com
