From 8439589bc7e74e4687797da8c0e88455decf5463 Mon Sep 17 00:00:00 2001 From: Andres Freund <andres@anarazel.de> Date: Sun, 5 May 2019 23:31:58 -0700 Subject: [PATCH] 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!) --- src/test/regress/expected/reindex_catalog.out | 9 +++++++-- src/test/regress/parallel_schedule | 5 ----- src/test/regress/serial_schedule | 1 - src/test/regress/sql/reindex_catalog.sql | 9 +++++++-- 4 files changed, 14 insertions(+), 10 deletions(-) diff --git a/src/test/regress/expected/reindex_catalog.out b/src/test/regress/expected/reindex_catalog.out index 142616fccbb..4b5fba49493 100644 --- 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 b9e9f647677..60854066114 100644 --- 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 f01b93a54f5..985f6c9f02f 100644 --- 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 2180ee5791a..87ecf52244f 100644 --- 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 -- GitLab