Invalid pg_upgrade error message during live check

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Invalid pg_upgrade error message during live check
Дата
Msg-id 20180105215839.GA25995@momjian.us
обсуждение исходный текст
Ответы Re: Invalid pg_upgrade error message during live check
Список pgsql-hackers
Pg_upgrade is able to run in --check mode when the old server is still
running.  Unfortunately, all supported versions of pg_upgrade generate
an incorrect (but harmless) "failure" message when doing this:

    $ pg_upgrade -b /u/pgsql.old/bin -B /u/pgsql/bin \
        -d /u/pgsql.old/data/ -D /u/pgsql/data --link --check

-->    *failure*
-->    Consult the last few lines of "pg_upgrade_server.log" for
-->    the probable cause of the failure.
    Performing Consistency Checks on Old Live Server
    ------------------------------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for invalid "unknown" user columns                 ok
    Checking for hash indexes                                   ok
    Checking for roles starting with "pg_"                      ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok

    *Clusters are compatible*

Embarrassingly, I found out about this bug when watching a presentation in
Frankfurt:

    PostgreSQL-Upgrade: Best Practices
    https://www.ittage.informatik-aktuell.de/programm/2017/postgresql-upgrade-best-practices/

and there is a blog entry about it too:

    https://blog.dbi-services.com/does-pg_upgrade-in-check-mode-raises-a-failure-when-the-old-cluster-is-running/

(Yeah, it stinks to be me.  :-) )

So, I looked into the code and it turns out that start_postmaster()
needs to run exec_prog() in a way that allows it to fail and continue
_without_ generating an error message.  There are other places that need
to run exec_prog() and allow it to fail and continue _and_ generate an
error message.

To fix this, I modified the exec_prog() API to separately control
reporting and exiting-on errors.  The attached patch does this and
generates the proper output:

    $ pg_upgrade -b /u/pgsql.old/bin -B /u/pgsql/bin \
        -d /u/pgsql.old/data/ -D /u/pgsql/data --link --check

    Performing Consistency Checks on Old Live Server
    ------------------------------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for invalid "unknown" user columns                 ok
    Checking for hash indexes                                   ok
    Checking for roles starting with "pg_"                      ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok
    
    *Clusters are compatible*

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

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Proposal: Local indexes for partitioned table
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: unique indexes on partitioned tables