The "DROP ACCESS METHOD gist2" test will require locking the index
to be dropped and then its table; while most ordinary operations
lock a table first then its index. While no concurrent test scripts
should be touching fast_emp4000, autovacuum might chance to be
processing that table when the DROP runs, resulting in a deadlock
failure. This is pretty rare but we see it in the buildfarm from
time to time.
To fix, acquire a lock on fast_emp4000 before issuing the DROP.
Since the point of the exercise is mostly to prevent buildfarm
failures, back-patch to 9.6 where this test was introduced.
Discussion: https://postgr.es/m/839004.
1599185607@sss.pgh.pa.us
index 84da403afc5db8832012056dafc8a7d68b0f37e0..b9dc82dd3c3a324cf10fc401fa1a5451c630fd87 100644 (file)
@@ -102,8 +102,13 @@ ERROR: cannot drop access method gist2 because other objects depend on it
DETAIL: index grect2ind2 depends on operator class box_ops for access method gist2
HINT: Use DROP ... CASCADE to drop the dependent objects too.
-- Drop access method cascade
+-- To prevent a (rare) deadlock against autovacuum,
+-- we must lock the table that owns the index that will be dropped
+BEGIN;
+LOCK TABLE fast_emp4000;
DROP ACCESS METHOD gist2 CASCADE;
NOTICE: drop cascades to index grect2ind2
+COMMIT;
--
-- Test table access methods
--
index a7f6de7e9be42a2cdff1471a4e7dac93989f9e3a..97df244d172a0902be6a6f2bf4b482ac0f820667 100644 (file)
DROP ACCESS METHOD gist2;
-- Drop access method cascade
+-- To prevent a (rare) deadlock against autovacuum,
+-- we must lock the table that owns the index that will be dropped
+BEGIN;
+LOCK TABLE fast_emp4000;
DROP ACCESS METHOD gist2 CASCADE;
+COMMIT;
--