Re: pg_upgrade and cross-library upgrades - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_upgrade and cross-library upgrades
Date
Msg-id ZKYIf0Gs2a23xqks@paquier.xyz
Whole thread Raw
In response to Re: pg_upgrade and cross-library upgrades  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade and cross-library upgrades
List pgsql-hackers
On Wed, Jul 05, 2023 at 07:03:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > 002_pg_upgrade.pl can test for presence or absence of pgcrypto by
> > grepping pg_config --configure for --with-ssl or --with-openssl.  If the
> > old cluster has it but the new doesn't, we must drop the
> > contrib_regression_pgcrypto database.
>
> Hmm, but you'd also need code to handle meson builds no?

Yes.  It is worth noting that pg_config (or its SQL function) would
report the switches for ./configure in its CONFIGURE field, but, err..
We report nothing under meson.  That's a problem.

> Could it
> be easier to look for the pgcrypto library in the new installation?

If all the contrib/ modules are handled, we'd need mapping rules for
everything listed in contrib/Makefile.

> Not entirely sure this is worth the effort.

I am not sure either..  Anyway, the buildfarm code does similar things
already, see around $bad_module in TestUpgradeXversion.pm, for
instance.  So this kind of workaround exists already.  It seems to me
that we should try to pull that out of the buildfarm code and have
that in the core module instead as a routine that would be used by the
in-core TAP tests of pg_upgrade and the buildfarm code.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Consider \v to the list of whitespace characters in the parser
Next
From: Michael Paquier
Date:
Subject: Re: Autogenerate some wait events code and documentation