Re: Extracting cross-version-upgrade knowledge from buildfarm client - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Extracting cross-version-upgrade knowledge from buildfarm client
Date
Msg-id 6e3ad198-88dc-0173-dd5d-3b232c220361@dunslane.net
Whole thread Raw
In response to Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Extracting cross-version-upgrade knowledge from buildfarm client
List pgsql-hackers


On 2023-07-19 We 07:05, Alvaro Herrera wrote:
I just hit a snag testing this.  It turns out that the
PostgreSQL::Version comparison stuff believes that 16beta2 < 16, which
sounds reasonable.  However, because of that, the AdjustUpgrade.pm
stanza that tries to drop tables public.gtest_normal_child{2} in
versions earlier than 16 fails, because by 16 these tables are dropped
in the test itself rather than left to linger, as was the case in
versions 15 and earlier.

So, if you try to run the pg_upgrade test with a dump created by
16beta2, it will fail to drop these tables (because they don't exist)
and the whole test fails.  Why hasn't the buildfarm detected this
problem?  I see that Drongo is happy, but I don't understand why.
Apparently, the AdjustUpgrade.pm stuff leaves no trace.


The buildfarm module assumes that no adjustments are necessary if the old and new versions are the same (e.g. HEAD to HEAD). And it never passes in a version like '16beta2'. It extracts the version number from the branch name, e.g. REL_16_STABLE => 16.



I can fix this either by using DROP IF EXISTS in that stanza, or by
making AdjustUpgrade use 'version <= 15'.  Any opinions on which to
prefer?


The trouble is this could well break the next time someone puts in a test like this.


Maybe we need to make AdjustUpgrade just look at the major version, something like:


   $old_version = PostgreSQL::Version->new($old_version->major);


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Disabling Heap-Only Tuples
Next
From: Thom Brown
Date:
Subject: Re: Disabling Heap-Only Tuples