Remove reindex_catalog test from test schedules.

As the test currently causes occasional deadlocks (due to the schema
cleanup from previous sessions potentially still running), and the
patch from f912d7dec2 has gotten a fair bit of buildfarm coverage,
remove the test from the test schedules. There's a set of minor
releases coming up.

Leave the tests in place, so it can manually be run using EXTRA_TESTS.

For now also leave it in master, as there's no imminent release, and
there's plenty (re-)index related work in 12. But we'll have to
disable it before long there too, unless somebody comes up with simple
enough fixes for the deadlock (I'm about to post a vague idea to the
list).

Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us
Backpatch: 9.4-11 (no master!)

diff --git a/src/test/regress/expected/reindex_catalog.out b/src/test/regress/expected/reindex_catalog.out
index 142616fccbbb4ece901108d7c5bda6e168f43648..4b5fba4949391053276fabcebc4c28cb9a847238 100644 (file)
--- a/src/test/regress/expected/reindex_catalog.out
+++ b/src/test/regress/expected/reindex_catalog.out
@@ -1,8 +1,8 @@
 --
 -- Check that system tables can be reindexed.
 --
--- Note that this test currently has to run without parallel tests
--- being scheduled, as currently reindex catalog tables can cause
+-- Note that this test currently is not included in the default
+-- schedules, as currently reindexing catalog tables can cause
 -- deadlocks:
 --
 -- * The lock upgrade between the ShareLock acquired for the reindex
@@ -16,6 +16,11 @@
 --   tables are routinely released before commit - therefore the lock
 --   held for reindexing doesn't guarantee that no running transaction
 --   performed modifications in the table underlying the index.
+--
+--   This is particularly problematic as such conflicts can be
+--   triggered even when run in isolation, as a previous session's
+--   temporary table cleanup might still be running (even when the
+--   session ended from a client perspective).
 -- Check reindexing of whole tables
 REINDEX TABLE pg_class; -- mapped, non-shared, critical
 REINDEX TABLE pg_index; -- non-mapped, non-shared, critical

diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index b9e9f64767794d71e5bfd7a95fa9f03e750574df..60854066114fd4d6c05364b08af0d77c29d0ef0e 100644 (file)
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -57,11 +57,6 @@ test: create_misc create_operator
 # These depend on the above two
 test: create_index create_view
 
-# ----------
-# Has to run in isolation, due to deadlock risk
-# ----------
-test: reindex_catalog
-
 # ----------
 # Another group of parallel tests
 # ----------

diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_schedule
index f01b93a54f5491984c17efc4c6b7dafc9af321e3..985f6c9f02f5b28101db87f2caf92e980f225bfa 100644 (file)
--- a/src/test/regress/serial_schedule
+++ b/src/test/regress/serial_schedule
@@ -61,7 +61,6 @@ test: create_misc
 test: create_operator
 test: create_index
 test: create_view
-test: reindex_catalog
 test: create_aggregate
 test: create_function_3
 test: create_cast

diff --git a/src/test/regress/sql/reindex_catalog.sql b/src/test/regress/sql/reindex_catalog.sql
index 2180ee5791acaca1bde2f19a9fc54ead6c3a64e2..87ecf52244f1ee06e2fc4e59c00b4131fb1a109f 100644 (file)
--- a/src/test/regress/sql/reindex_catalog.sql
+++ b/src/test/regress/sql/reindex_catalog.sql
@@ -1,8 +1,8 @@
 --
 -- Check that system tables can be reindexed.
 --
--- Note that this test currently has to run without parallel tests
--- being scheduled, as currently reindex catalog tables can cause
+-- Note that this test currently is not included in the default
+-- schedules, as currently reindexing catalog tables can cause
 -- deadlocks:
 --
 -- * The lock upgrade between the ShareLock acquired for the reindex
@@ -16,6 +16,11 @@
 --   tables are routinely released before commit - therefore the lock
 --   held for reindexing doesn't guarantee that no running transaction
 --   performed modifications in the table underlying the index.
+--
+--   This is particularly problematic as such conflicts can be
+--   triggered even when run in isolation, as a previous session's
+--   temporary table cleanup might still be running (even when the
+--   session ended from a client perspective).
 
 
 -- Check reindexing of whole tables