Re: pg_upgrade and cross-library upgrades
> On 6 Jul 2023, at 02:19, Michael Paquier wrote: > On Wed, Jul 05, 2023 at 07:03:56AM -0400, Tom Lane wrote: >> Not entirely sure this is worth the effort. > > I am not sure either.. I can't see off the cuff that it would bring better test coverage or find bugs relative to the effort of making it stable. > 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. That however, would be a more interesting outcome. -- Daniel Gustafsson
Re: pg_upgrade and cross-library upgrades
On Wed, Jul 05, 2023 at 07:03:56AM -0400, Tom Lane wrote: > Alvaro Herrera 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 signature.asc Description: PGP signature
Re: pg_upgrade and cross-library upgrades
Alvaro Herrera 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? Could it be easier to look for the pgcrypto library in the new installation? Not entirely sure this is worth the effort. regards, tom lane
Re: pg_upgrade and cross-library upgrades
On 2023-Jul-05, Michael Paquier wrote: > The same thing as HEAD could be done on its back-branches by removing > --with-openssl and bring more consistency, but pg_upgrade has never > been good at handling upgrades with different library requirements. > Something I am wondering is if AdjustUpgrade.pm could gain more > knowledge in this area, though I am unsure how much could be achieved > as this module has only object-level knowledge. Hmm, let's explore the AdjustUpgrade.pm path a bit more: 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. I think we would need a new function in AdjustUpgrade.pm (or an API change to adjust_database_contents) so that we can add the DROP DATABASE command conditionally. This seems easily extended to contrib/xml2 also. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
Re: pg_upgrade and cross-library upgrades
On Wed, Jul 05, 2023 at 06:00:25PM +1200, Thomas Munro wrote: > If this were my animal and if the hardware couldn't be > upgraded to a modern distro for technical reasons like a de-supported > architecture, I would now disable HEAD, or more likely give the whole > machine a respectful send-off ceremony and move on. Amen. -- Michael signature.asc Description: PGP signature
Re: pg_upgrade and cross-library upgrades
On Wed, Jul 5, 2023 at 4:29 PM Michael Paquier wrote: > Thoughts? I am grateful for all the bug discoveries that these Debian 7 animals provided in their time, but at this point we're unlikely to learn things that are useful to our mission from them. It costs our community time to talk about each of these issues, re-discovering old GCC bugs etc. If this were my animal and if the hardware couldn't be upgraded to a modern distro for technical reasons like a de-supported architecture, I would now disable HEAD, or more likely give the whole machine a respectful send-off ceremony and move on.
pg_upgrade and cross-library upgrades
Hi all, After removing --with-openssl from its build of HEAD, snapper has begun failing in the pg_upgrade path 11->HEAD, because it attempts pg_upgrade from binaries that have OpenSSL to builds without it: https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=snapper=HEAD Using the TAP tests of pg_upgrade, I can get the same failure with the following steps: 1) Setup instance based on Postgres 11, compiled with OpenSSL. 2) Run a few tests and tap a dump: # From 11 source tree: make installcheck cd contrib/pgcrypto/ USE_MODULE_DB=1 make installcheck ~/path/to/11/bin/pg_dumpall -f /tmp/olddump.sql 3) From 16~ source tree, compiled without OpenSSL: cd src/bin/pg_upgrade olddump=/tmp/olddump.sql oldinstall=~/path/to/11/ make check And then you would get: could not load library "$libdir/pgcrypto": ERROR: could not access file "$libdir/pgcrypto": No such file or directory In database: contrib_regression_pgcrypto The same thing as HEAD could be done on its back-branches by removing --with-openssl and bring more consistency, but pg_upgrade has never been good at handling upgrades with different library requirements. Something I am wondering is if AdjustUpgrade.pm could gain more knowledge in this area, though I am unsure how much could be achieved as this module has only object-level knowledge. Anyway, that's not really limited to pgcrypto, any extension with different cross-library requirements would see that. One example, xml2 could be compiled with libxml and without libxslt. It is less popular than pgcrypto, but the failure should be the same. I'd rather choose the shortcut of removing --with-openssl from snapper in the short term, but that does nothing for the root issue in the long-term. Thoughts? -- Michael signature.asc Description: PGP signature
