From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new --maintenance-db options |
Date: | 2012-06-25 19:12:00 |
Message-ID: | 1340651112-sup-8588@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Robert Haas's message of lun jun 25 14:58:25 -0400 2012:
>
> On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
> > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
> >> 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.
> >
> > I think pg_upgrade could do this one task by using a standalone backend
> > instead of a full-blown postmaster. It should be easy enough ...
>
> Maybe, but it seems like baking even more hackery into a tool that's
> already got too much hackery. It's also hard for pg_upgrade to know
> things like - whether pg_hba.conf prohibits access to certain
> users/databases/etc. or just requires the use of authentication
> methods that happen to fail. From pg_upgrade's perspective, it would
> be nice to have a flag that starts the server in some mode where
> nobody but pg_upgrade can connect to it and all connections are
> automatically allowed, but it's not exactly clear how to implement
> "nobody but pg_upgrade can connect to it".
Well, have it specify a private socket directory, listen only on that
(not TCP), and bypass all pg_hba rules.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-25 19:17:46 | Re: Catalog/Metadata consistency during changeset extraction from wal |
Previous Message | Robert Haas | 2012-06-25 18:58:25 | Re: new --maintenance-db options |