Re: pg_upgrade and cross-library upgrades

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: 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-05 08:49:35
Message-ID: 20230705084935.xuctwm5andme4ewz@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-07-05 08:58:00 Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes
Previous Message Matthias van de Meent 2023-07-05 08:44:00 Re: Parallel CREATE INDEX for BRIN indexes