From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: format of pg_upgrade loadable_libraries warning |
Date: | 2019-10-04 21:37:46 |
Message-ID: | 20191004213746.GD29227@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 2, 2019 at 12:23:37PM -0500, Justin Pryzby wrote:
> 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 :(
Understood. This is a general problem with the way pg_upgrade displays
errors and the databases/objects associated with them. The attached
patch fixes the output text to say "in database", e.g.:
Could not load library "$libdir/pgfincore": ERROR: could not access file "$libdir/pgfincore": No such file or directory
in database: postgres
in database: too
Would intenting help too? I am inclined to fix this only head, and not
to backpatch the change.
--
Bruce Momjian <bruce(at)momjian(dot)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 | Content-Type | Size |
---|---|---|
error-found.diff | text/x-diff | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-10-04 21:40:08 | Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays |
Previous Message | Tomas Vondra | 2019-10-04 21:31:00 | Re: Transparent Data Encryption (TDE) and encrypted files |