postgres.git / summary / log / commit / refs

commit    d0518e965e6489ff2df0a71953e56656c710141a
Author:   Michael Paquier <michael@paquier.xyz>
Date:     Wed Dec 10 03:47:23 2025 +0000
First released in: 17.8, 18.2

    Fix failures with cross-version pg_upgrade tests
    
    Buildfarm members skimmer and crake have reported that pg_upgrade
    running from v18 fails due to the changes of d52c24b0f808, with the
    expectations that the objects removed in the test module
    injection_points should still be present post upgrades, but the test
    module does not have them anymore.
    
    The origin of the issue is that the following test modules depend on
    injection_points, but they do not drop the extension once the tests
    finish, leaving its traces in the dumps used for the upgrades:
    - gin, down to v17
    - typcache, down to v18
    - nbtree, HEAD-only
    Test modules have no upgrade requirements, as they are used only for..
    Tests, so there is no point in keeping them around.
    
    An alternative solution would be to drop the databases created by these
    modules in AdjustUpgrade.pm, but the solution of this commit to drop the
    extension is simpler.  Note that there would be a catch if using a
    solution based on AdjustUpgrade.pm as the database name used for the
    test runs differs between configure and meson:
    - configure relies on USE_MODULE_DB for the database name unicity, that
    would build a database name based on the *first* entry of REGRESS, that
    lists all the SQL tests.
    - meson relies on a "name" field.
    
    For example, for the test module "gin", the regression database is named
    "regression_gin" under meson, while it is more complex for configure, as
    of "contrib_regression_gin_incomplete_splits".  So a AdjustUpgrade.pm
    would need a set of DROP DATABASE IF EXISTS to solve this issue, to cope
    with each build system.
    
    The failure has been caused by d52c24b0f808, and the problem can happen
    with upgrade dumps from v17 and v18 to HEAD.  This problem is not
    currently reachable in the back-branches, but it could be possible that
    a future change in injection_points in stable branches invalidates this
    theory, so this commit is applied down to v17 in the test modules that
    matter.
    
    Per discussion with Tom Lane and Heikki Linnakangas.
    
    Discussion: https://postgr.es/m/2899652.1765167313@sss.pgh.pa.us
    Backpatch-through: 17


 src/test/modules/gin/expected/gin_incomplete_splits.out | 1 +
 src/test/modules/gin/sql/gin_incomplete_splits.sql      | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/src/test/modules/gin/expected/gin_incomplete_splits.out b/src/test/modules/gin/expected/gin_incomplete_splits.out
index 15574e547ac..0f3ac9a0466 100644
--- a/src/test/modules/gin/expected/gin_incomplete_splits.out
+++ b/src/test/modules/gin/expected/gin_incomplete_splits.out
@@ -192,3 +192,4 @@ SELECT injection_points_detach('gin-finish-incomplete-split');
  
 (1 row)
 
+drop extension injection_points;
diff --git a/src/test/modules/gin/sql/gin_incomplete_splits.sql b/src/test/modules/gin/sql/gin_incomplete_splits.sql
index ebf0f620f0c..d451257c275 100644
--- a/src/test/modules/gin/sql/gin_incomplete_splits.sql
+++ b/src/test/modules/gin/sql/gin_incomplete_splits.sql
@@ -148,3 +148,5 @@ select insert_n(:next_i, 10) as next_i
 select verify(:next_i);
 
 SELECT injection_points_detach('gin-finish-incomplete-split');
+
+drop extension injection_points;


[parent: f24af0e04cef]