Invalid pg_upgrade error message during live check - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Invalid pg_upgrade error message during live check |
Date | |
Msg-id | 20180105215839.GA25995@momjian.us Whole thread Raw |
Responses |
Re: Invalid pg_upgrade error message during live check
|
List | 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 +
Attachment
pgsql-hackers by date: