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