Skip to content
Snippets Groups Projects
Commit 70200d0d authored by Andres Freund's avatar Andres Freund
Browse files

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 f912d7de 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!)
parent 21de9ae1
No related branches found
No related tags found
No related merge requests found
-- --
-- Check that system tables can be reindexed. -- Check that system tables can be reindexed.
-- --
-- Note that this test currently has to run without parallel tests -- Note that this test currently is not included in the default
-- being scheduled, as currently reindex catalog tables can cause -- schedules, as currently reindexing catalog tables can cause
-- deadlocks: -- deadlocks:
-- --
-- * The lock upgrade between the ShareLock acquired for the reindex -- * The lock upgrade between the ShareLock acquired for the reindex
...@@ -16,6 +16,11 @@ ...@@ -16,6 +16,11 @@
-- tables are routinely released before commit - therefore the lock -- tables are routinely released before commit - therefore the lock
-- held for reindexing doesn't guarantee that no running transaction -- held for reindexing doesn't guarantee that no running transaction
-- performed modifications in the table underlying the index. -- 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 -- Check reindexing of whole tables
REINDEX TABLE pg_class; -- mapped, non-shared, critical REINDEX TABLE pg_class; -- mapped, non-shared, critical
REINDEX TABLE pg_index; -- non-mapped, non-shared, critical REINDEX TABLE pg_index; -- non-mapped, non-shared, critical
......
...@@ -56,11 +56,6 @@ test: create_misc create_operator ...@@ -56,11 +56,6 @@ test: create_misc create_operator
# These depend on the above two # These depend on the above two
test: create_index create_view test: create_index create_view
# ----------
# Has to run in isolation, due to deadlock risk
# ----------
test: reindex_catalog
# ---------- # ----------
# Another group of parallel tests # Another group of parallel tests
# ---------- # ----------
......
...@@ -60,7 +60,6 @@ test: create_misc ...@@ -60,7 +60,6 @@ test: create_misc
test: create_operator test: create_operator
test: create_index test: create_index
test: create_view test: create_view
test: reindex_catalog
test: create_aggregate test: create_aggregate
test: create_function_3 test: create_function_3
test: create_cast test: create_cast
......
-- --
-- Check that system tables can be reindexed. -- Check that system tables can be reindexed.
-- --
-- Note that this test currently has to run without parallel tests -- Note that this test currently is not included in the default
-- being scheduled, as currently reindex catalog tables can cause -- schedules, as currently reindexing catalog tables can cause
-- deadlocks: -- deadlocks:
-- --
-- * The lock upgrade between the ShareLock acquired for the reindex -- * The lock upgrade between the ShareLock acquired for the reindex
...@@ -16,6 +16,11 @@ ...@@ -16,6 +16,11 @@
-- tables are routinely released before commit - therefore the lock -- tables are routinely released before commit - therefore the lock
-- held for reindexing doesn't guarantee that no running transaction -- held for reindexing doesn't guarantee that no running transaction
-- performed modifications in the table underlying the index. -- 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 -- Check reindexing of whole tables
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment