Re: Finding database for pg_upgrade missing library

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Finding database for pg_upgrade missing library
Date: 2018-07-28 16:39:59
Message-ID: 20180728163959.GB22661@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 24, 2018 at 10:33:48AM +0200, Daniel Gustafsson wrote:
> > Looking at the code, we do a qsort(), then detect (since they are all
> > now adjacent) and remove the duplicate references to the library. What
> > I think should be done is to move the duplicate detection down to the
> > place where we check for the library, then print all the database names
> > of the duplicates if we don't find the library. I guess we either need
> > a separate array for the database name, or a 'struct' that holds the
> > library name and database name.
>
> I went for the solution of not removing the duplicates in the first pass, and
> instead dedup during reporting. It’s sort of unelegant in that it consumes
> more memory than strictly limited, but the simplicity of the code weighs up
> IMO. An additional step to free the libraries struct member before continuing
> could perhaps be worth it?

I have applied a patch to implement this for PG 12:

https://git.postgresql.org/pg/commitdiff/60e3bd1d7f92430b24b710ecf0559656eb8ed499

I looked at your patch and made some adjustments:

sort by library name, then database id (this last part was
missing)
your 'continue' block repeatedly probed the same library name if
the library was found
restructured the loop to report the database name at the end of
the loop, not in a 'continue'
report the database name in a format like other pg_upgrade error
text files

Thanks.

--
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 +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Florent 2018-07-28 16:46:02 RE: [Proposal] Add accumulated statistics for wait event
Previous Message Bruce Momjian 2018-07-28 16:35:06 Re: [HACKERS] pg_upgrade and missing loadable libraries