Re: pg_upgrade fails for non-postgres user

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade fails for non-postgres user
Дата
Msg-id 201102010125.p111PxU22660@momjian.us
обсуждение исходный текст
Ответ на pg_upgrade fails for non-postgres user  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg_upgrade fails for non-postgres user  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
Magnus Hagander wrote:
> 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.

I have found that this problem only affects PG 9.1 and is not part of
released PG 9.0 because we don't restore pg_authid in 9.0 (we don't need
to because we have no pg_largeobject_metadata table in PG 8.4).

I have applied a modified version of your patch to always retore into
the 'postgres' database rather than the OS user.  I thought we created
an os-user-named database, but it seems that database is always called
'postgres' but is owned by the OS user.  That seems kind of
inconsistent, but no matter.

I did not modify what we use for psql because everything else in
pg_upgrade connects to template1.  I am surprised that we recommend
restoring pg_dump to the 'postgres' database rather than template1, and
have no idea why we do that.  pg_dumpall also favors the 'postgres'
database:

       -l dbname, --database=dbname
           Specifies the name of the database to connect to to
           dump global objects and discover what other databases
           should be dumped. If not specified, the postgres
           database will be used, and if that does not exist,
           template1 will be used.

Anyway, it seems good to keep consistent and I defined a macro to record
what pg_dumpall uses as a hard-coded database for the restore.
pg_dumpall always assumes the 'postgres' database exists, so we are OK
there.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.c
index 294f58b..d3e1fef 100644
*** a/contrib/pg_upgrade/pg_upgrade.c
--- b/contrib/pg_upgrade/pg_upgrade.c
*************** static void set_frozenxids(void);
*** 50,55 ****
--- 50,58 ----
  static void setup(char *argv0, bool live_check);
  static void cleanup(void);

+ /* This is the database used by pg_dumpall to restore global tables */
+ #define GLOBAL_DUMP_DB    "postgres"
+
  ClusterInfo old_cluster, new_cluster;
  OSInfo        os_info;

*************** prepare_new_databases(void)
*** 226,235 ****
      prep_status("Creating databases in the new cluster");

      /*
!      *    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);

      /*
       * We have to create the databases first so we can install support
--- 229,238 ----
      prep_status("Creating databases in the new cluster");

      /*
!      *    Install support functions in the global-restore database
!      *    to preserve pg_authid.oid.
       */
!     install_support_functions_in_new_db(GLOBAL_DUMP_DB);

      /*
       * We have to create the databases first so we can install support
*************** create_new_objects(void)
*** 266,272 ****
          DbInfo       *new_db = &new_cluster.dbarr.dbs[dbnum];

          /* skip db we already installed */
!         if (strcmp(new_db->db_name, os_info.user) != 0)
              install_support_functions_in_new_db(new_db->db_name);
      }
      check_ok();
--- 269,275 ----
          DbInfo       *new_db = &new_cluster.dbarr.dbs[dbnum];

          /* skip db we already installed */
!         if (strcmp(new_db->db_name, GLOBAL_DUMP_DB) != 0)
              install_support_functions_in_new_db(new_db->db_name);
      }
      check_ok();

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error code for "terminating connection due to conflict with recovery"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Error code for "terminating connection due to conflict with recovery"