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

From Tom Lane
Subject Re: Extracting cross-version-upgrade knowledge from buildfarm client
Date
Msg-id 3752447.1674070321@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extracting cross-version-upgrade knowledge from buildfarm client
List pgsql-hackers
One more thing before we move on from this topic.  I'd been testing
modified versions of the AdjustUpgrade.pm logic by building from a
--from-source source tree, which seemed way easier than dealing
with a private git repo.  As it stands, TestUpgradeXversion.pm
refuses to run under $from_source, but I just diked that check out
and it seemed to work fine for my purposes.  Now, that's going to be
a regular need going forward, so I'd like to not need a hacked version
of the BF client code to do it.

Also, your committed version of TestUpgradeXversion.pm breaks that
use-case because you did

-   unshift(@INC, "$self->{pgsql}/src/test/perl");
+   unshift(@INC, "$self->{buildroot}/$this_branch/pgsql/src/test/perl");

which AFAICS is an empty directory in a $from_source run.

I suppose that the reason for not running under $from_source is to
avoid corrupting the saved installations with unofficial versions.
However, couldn't we skip the "save" step and still run the upgrade
tests against whatever we have saved?  (Maybe skip the same-version
test, as it's not quite reflecting any real case then.)

Here's a quick draft patch showing what I have in mind.  There may
well be a better way to deal with the wheres-the-source issue than
what is in hunk 2.  Also, I didn't reindent the unchanged code in
sub installcheck, and I didn't add anything about skipping
same-version tests.

            regards, tom lane

diff --git a/PGBuild/Modules/TestUpgradeXversion.pm b/PGBuild/Modules/TestUpgradeXversion.pm
index a784686..408432d 100644
--- a/PGBuild/Modules/TestUpgradeXversion.pm
+++ b/PGBuild/Modules/TestUpgradeXversion.pm
@@ -51,8 +51,6 @@ sub setup
     my $conf      = shift;    # ref to the whole config object
     my $pgsql     = shift;    # postgres build dir

-    return if $from_source;
-
     return if $branch !~ /^(?:HEAD|REL_?\d+(?:_\d+)?_STABLE)$/;

     my $animal = $conf->{animal};
@@ -351,7 +349,16 @@ sub test_upgrade    ## no critic (Subroutines::ProhibitManyArgs)
       if $verbose;

     # load helper module from source tree
-    unshift(@INC, "$self->{buildroot}/$this_branch/pgsql/src/test/perl");
+    my $source_tree;
+    if ($from_source)
+    {
+        $source_tree = $self->{pgsql};
+    }
+    else
+    {
+        $source_tree = "$self->{buildroot}/$this_branch/pgsql";
+    }
+    unshift(@INC, "$source_tree/src/test/perl");
     require PostgreSQL::Test::AdjustUpgrade;
     PostgreSQL::Test::AdjustUpgrade->import;
     shift(@INC);
@@ -694,6 +701,11 @@ sub installcheck
     my $upgrade_loc          = "$upgrade_install_root/$this_branch";
     my $installdir           = "$upgrade_loc/inst";

+    # Don't save in a $from_source build: we want the saved trees always
+    # to correspond to branch tips of the animal's standard repo.  We can
+    # perform upgrade tests against previously-saved trees, though.
+    if (!$from_source)
+    {
     # for saving we need an exclusive lock.
     get_lock($self, $this_branch, 1);

@@ -716,6 +728,7 @@ sub installcheck
       if ($verbose > 1);
     send_result('XversionUpgradeSave', $status, \@saveout) if $status;
     $steps_completed .= " XVersionUpgradeSave";
+    }

     # in saveonly mode our work is done
     return if $ENV{PG_UPGRADE_SAVE_ONLY};
@@ -744,7 +757,7 @@ sub installcheck
         # other branch from being removed or changed under us.
         get_lock($self, $oversion, 0);

-        $status =
+        my $status =
           test_upgrade($self, $save_env, $this_branch, $upgrade_install_root,
             $dport, $install_loc, $other_branch) ? 0 : 1;


pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: document the need to analyze partitioned tables
Next
From: Robert Haas
Date:
Subject: Re: Non-superuser subscription owners