Re: pg_upgrade and cross-library upgrades

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgbf(at)twiska(dot)com
Subject: Re: pg_upgrade and cross-library upgrades
Date: 2023-07-06 00:19:11
Message-ID: ZKYIf0Gs2a23xqks@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 05, 2023 at 07:03:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-07-06 00:36:12 Re: Autogenerate some wait events code and documentation
Previous Message David Rowley 2023-07-05 23:55:36 Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower