Re: new --maintenance-db options

On Sat, Jun 23, 2012 at 6:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> About the new --maintenance-db options:
>
> Why was this option not added to createuser and dropuser?  In the
> original discussion[0] they were mentioned, but it apparently never made
> it into the code.

Oops.  That was an oversight.

> I find the name to be unfortunate.  For example, I think of running
> vacuum as "maintenance".  So running vacuumdb --maintenance-db=X would
> imply that the vacuum maintenance is done on X.  In fact, the whole
> point of this option is to find out where the maintenance is to be run,
> not to run the maintenance.  Maybe something like --initial-db would be
> better?

As Dave says, I picked this because pgAdmin has long used that terminology.

> What is the purpose of these options?  The initial discussion was
> unclear on this.  The documentation contains no explanation of why they
> should be used.  If we want to really support the case where both
> postgres and template1 are removed, an environment variable might be
> more useful than requiring this to be typed out for every command.
>
> [0]: http://archives.postgresql.org/message-id/CA+TgmoaCjWSiS9nNqJGAamL1vg6C8B6O1nDgqnUCa2Gm00dNfg@mail.gmail.com

Well, I would be opposed to having ONLY an environment variable,
because I think that anything that can be controlled via an
environment variable should be able to be overridden on the command
line.  It might be OK to have both an environment variable AND a
command-line option, but I tend to thing it's too marginal to justify
that.

In retrospect, it seems as though it might have been a good idea to
make the postgres database read-only and undroppable, so that all
client utilities could count on being able to connect to it and get a
list of databases in the cluster without the need for all this
complexity.  Or else having some other way for a client to
authenticate and list out all the available databases.  In the absence
of such a mechanism, I don't think we can turn around and say that not
having a postgres database is an unsupported configuration, and
therefore we need some way to cope with it when it happens.

I think the original report that prompted this change was a complaint
that pg_upgrade failed when the postgres database had been dropped.
Now, admittedly, pg_upgrade fails for all kinds of crazy stupid
reasons and the chances of fixing that problem completely any time in
the next 5 years do not seem good, but that's not a reason not to keep
plugging the holes we can.  Anyhow, the same commit that introduced
--maintenance-db "fixed" that problem by making arranging to try both
postgres and template1 before giving up...  but have two hard-coded
database names either of which can be dropped or renamed seems only
marginally better than having one, hence the switch.  Really, I think
pg_upgrade needs this option too, unless we're going to kill the
problem at its root by providing a reliable way to enumerate database
names without first knowing the name one that you can connect to.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company