Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iFiLt-00040t-I5 for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Oct 2019 17:23:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iFiLs-0000Al-BM for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Oct 2019 17:23:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iFiLr-0000Ab-Uf for pgsql-hackers@lists.postgresql.org; Wed, 02 Oct 2019 17:23:48 +0000 Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iFiLo-0002j0-In for pgsql-hackers@lists.postgresql.org; Wed, 02 Oct 2019 17:23:47 +0000 Received: by mail-io1-xd42.google.com with SMTP id b136so58744743iof.3 for ; Wed, 02 Oct 2019 10:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=CNz/BMfntKhJteZ5ROcDl2s0a5LbLm3R3CWstwIztd0=; b=e8QP6jbd0gn8yoJZMkrrtK4R2POuAsp280fPD5L8EIgg8q8hCzrjq1rXY0R5oYMgDZ TPJLJCRPeTN9ZHFE2OBTP1MZgtkcqYBapiCeJlan35qx9TPJ/FYWg3e3nQPigp7XjsXT CGhtx48DIeFhEYNFFmKs2r7byeZlG/K1qvneJgrsvEqUKaQrxFS+piVrmUryrn+dG/ZQ AF9HRAFQeTFBndC49Ml1wQmF3mkd95SMun3z68RtaCjxGDOFk1O0OHEBlNZKm+LXe8Y5 eTLhLRsYcYPYgAIc5S8IIZpOvKdMXoVyPJceh0g0lU+lnbycozNNgs827eHgoEbAhJHZ lyHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=CNz/BMfntKhJteZ5ROcDl2s0a5LbLm3R3CWstwIztd0=; b=eG4EYuMF4t6gLZKvblwjZMsJu8yzgx27C6CN9OSDndV9SudIRS8kMqBOW0Ii6gFAxu YbcTLRnlkwXYQMtU9CjnSMhjdWs45tXccjB5ATCAHR2NJjW0gTwRVCmfbtXRARZOXia4 zWam2pUIQrEoxp2qGnxHGqPc1vmtTcXgCu4amBpqV/4yHbaa6W7QJqaNtC+WTzeFyasu Ujv57ATVcWZiIWZiypesCZwa2jzABTKbwP/zlUEh84oiEPFnhwA0gQ/PdJZYKw/6ipbp GScsAChw3ecx6Qkti9+QVUGwimE3KPGp/SXDYBkWQsLNGeSBzLgWO5Z9G9RNOW149J5j Zp9Q== X-Gm-Message-State: APjAAAW3d4+IdDWDifNYqAJPhuiZqcP/VW9Kb3FzHrU4STXM6zswoheS g1Qo3iuBInSYd9ypjCKtlyaFGTsE07g= X-Google-Smtp-Source: APXvYqzPR5XwNKXRielyR28hs1eJC++8uGWyZ8lprPosGq3V3CT/eugHtT4XFqyDKAU6HuDa3EH14w== X-Received: by 2002:a5d:89da:: with SMTP id a26mr4019588iot.61.1570037021862; Wed, 02 Oct 2019 10:23:41 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k66sm9540396iof.25.2019.10.02.10.23.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 10:23:40 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 4B3CE800CF1; Wed, 2 Oct 2019 12:23:37 -0500 (CDT) Date: Wed, 2 Oct 2019 12:23:37 -0500 From: Justin Pryzby To: pgsql-hackers@lists.postgresql.org Cc: Bruce Momjian , Daniel Gustafsson Subject: format of pg_upgrade loadable_libraries warning Message-ID: <20191002172337.GC9680@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Regarding the previous thread and commit here: https://www.postgresql.org/message-id/flat/20180713162815.GA3835%40momjian.us https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=60e3bd1d7f92430b24b710ecf0559656eb8ed499 I'm suggesting to reformat the warning, which I found to be misleading: |could not load library "$libdir/pgfincore": ERROR: could not access file "$libdir/pgfincore": No such file or directory |Database: postgres |Database: too To me that reads as "error message" followed by successful processing of two, named database, and not "error message followed by list of databases for which that error was experienced". Essentially, the database names are themselves the "error", and the message is a prefix indicating the library version; but normally, error-looking things are output without a "prefix", since they weren't anticipated. The existing check is optimized to check each library once, but then outputs each database which would try to load it. That's an implementation detail, but adds to confusion, since it shows a single error-looking thing which might apply to multiple DBs (not obvious to me that it's associated with an DB at all). That leads me to believe that after I "DROP EXTENSION" once, I can reasonably expect the upgrade to complete, which has a good chance of being wrong, and is exactly what the patch was intended to avoid :( To reproduce: $ /usr/pgsql-11/bin/initdb -D ./pgtestlib11 $ /usr/pgsql-12/bin/initdb -D ./pgtestlib12 $ /usr/pgsql-11/bin/pg_ctl -D ./pgtestlib11 -o '-c port=5678 -c unix_socket_directories=/tmp' start $ psql postgres -h /tmp -p 5678 -c 'CREATE EXTENSION pgfincore' -c 'CREATE DATABASE too' $ psql too -h /tmp -p 5678 -c 'CREATE EXTENSION pgfincore' $ /usr/pgsql-11/bin/pg_ctl -D ./pgtestlib11 stop $ /usr/pgsql-12/bin/pg_upgrade -b /usr/pgsql-11/bin -B /usr/pgsql-12/bin -d ./pgtestlib11 -D pgtestlib12 $ cat loadable_libraries.txt Could not load library "$libdir/pgfincore": ERROR: could not access file "$libdir/pgfincore": No such file or directory Database: postgres Database: too I concede that the situation is clearer if there are multiple libraries causing errors, especially in overlapping list of databases: |[pryzbyj@database ~]$ cat loadable_libraries.txt |could not load library "$libdir/pg_repack": ERROR: could not access file "$libdir/pg_repack": No such file or directory |Database: postgres |Database: too |could not load library "$libdir/pgfincore": ERROR: could not access file "$libdir/pgfincore": No such file or directory |Database: postgres |Database: too I think the list of databases should be formatted to indicate its association with the preceding error by indentation and verbage, or larger refactoring to present in a list, like: "Databases with library which failed to load: %s: %s", PQerrorMessage(conn), list_of_dbs_loading_that_lib Justin --EVF5PPMfhYS0aIcm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-Indent-and-repeat-name-of-library-failing-to-load.patch" From 513deb19f4741e717f73d0ba6163331107cfb616 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Wed, 2 Oct 2019 12:08:37 -0500 Subject: [PATCH v1] Indent and repeat name of library failing to load --- src/bin/pg_upgrade/function.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/bin/pg_upgrade/function.c b/src/bin/pg_upgrade/function.c index 0c66d1c..68d3634 100644 --- a/src/bin/pg_upgrade/function.c +++ b/src/bin/pg_upgrade/function.c @@ -255,9 +255,16 @@ check_loadable_libraries(void) PQclear(res); } - if (was_load_failure) - fprintf(script, _("Database: %s\n"), + if (was_load_failure) { + /* + * Having probed that the library failed to load once, + * assume that it won't load in any DB and output each + * DB which would try to load it. + */ + fprintf(script, _(" - database loading %s: %s\n"), + lib, old_cluster.dbarr.dbs[os_info.libraries[libnum].dbnum].db_name); + } } PQfinish(conn); -- 2.7.4 --EVF5PPMfhYS0aIcm--