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&br=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
