From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: new --maintenance-db options |
Date: | 2012-06-29 19:32:26 |
Message-ID: | 20120629193226.GB13225@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 25, 2012 at 11:57:36AM -0400, Robert Haas wrote:
> 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.
Well, we certainly don't allow 'template1' to be dropped:
test=> DROP DATABASE template1;
ERROR: cannot drop a template database
so you could make the argument that making 'postgres' undroppable seem
reasonable. I should point out that it was EnterpriseDB that complained
about this related to their Advanced Server product, that doesn't have a
'postgres' database, but an 'edb' one. I said that was their problem,
but when community users said they also dropped the 'postgres' database,
it became a community problem too.
Where are we going on this for PG 9.2? 9.3? I hate to ship options in
9.2 that will be gone in 9.3.
FYI, we do allow the 'template1' database to be renamed:
test=> ALTER DATABASE template1 RENAME TO template2;
ALTER DATABASE
Oops. TODO?
> 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
Actually, 'template1' can't be dropped like 'postgres', but can be
renamed (which I think needs fixing). I think falling back to template1
for missing 'postgres' database was the goal there.
> 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.
pg_upgrade doesn't use --maintenance-db because the tools now fallback
to template1, which again brings up the question of the usefulness of
the --maintenance-db options.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-06-29 19:33:56 | Re: new --maintenance-db options |
Previous Message | Bruce Momjian | 2012-06-29 19:07:41 | Re: new --maintenance-db options |