On Mon, Jun 25, 2012 at 02:58:25PM -0400, Robert Haas wrote:
> On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
> <alvhe...@commandprompt.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".
pg_upgrade already starts the postmaster with a -b option that disables
non-super-user logins:
/*
* Binary upgrades only allowed super-user connections
*/
if (IsBinaryUpgrade && !am_superuser)
{
ereport(FATAL,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("must be superuser to connect in binary upgrade mode")));
}
It also uses port 50432 by default. Not sure what else we can do.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
