I just tried doing pg_upgrade on a database when logged in as user
"mha" rather than "postgres" on my system. And it failed. Even though
the db was initialized with superuser "mha". The reason for this was
that pg_upgrade tried to connect to the database "mha" (hardcoded to
be the db username), and that certainly didn't exist.
When that was fixed, I realized the psql command to create the
datanbases connect to database "template1" only to immediately switch
to database "postgres", which also seems rather pointless.
Attach patch makes it connect to the "postgres" database instead of
$USER, and then also changes the psql command to actually use it.
I know way too little about pg_upgrade to tell if this is fully safe,
but it does fix the problem in my installation.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.c
index 294f58b..be9519c 100644
--- a/contrib/pg_upgrade/pg_upgrade.c
+++ b/contrib/pg_upgrade/pg_upgrade.c
@@ -229,7 +229,7 @@ prepare_new_databases(void)
* Install support functions in the database accessed by
* GLOBALS_DUMP_FILE because it can preserve pg_authid.oid.
*/
- install_support_functions_in_new_db(os_info.user);
+ install_support_functions_in_new_db("postgres");
/*
* We have to create the databases first so we can install support
@@ -239,7 +239,7 @@ prepare_new_databases(void)
SYSTEMQUOTE "\"%s/psql\" --set ON_ERROR_STOP=on "
/* --no-psqlrc prevents AUTOCOMMIT=off */
"--no-psqlrc --port %d --username \"%s\" "
- "-f \"%s/%s\" --dbname template1 >> \"%s\"" SYSTEMQUOTE,
+ "-f \"%s/%s\" --dbname postgres >> \"%s\"" SYSTEMQUOTE,
new_cluster.bindir, new_cluster.port, os_info.user, os_info.cwd,
GLOBALS_DUMP_FILE, log_opts.filename);
check_ok();
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
