]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix risk of deadlock failure while dropping a partitioned index.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 21 Mar 2022 16:22:13 +0000 (12:22 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 21 Mar 2022 16:22:13 +0000 (12:22 -0400)
commit05ccf974cd75d3a95869c4ce4b96fdbc10e663cf
treedee0ae9bd7d6e24ba7c3b1fbb89075c3aadb88f1
parenta1efc8f8c820a1e94eb26f7c93e4c6f6e9b277d6
Fix risk of deadlock failure while dropping a partitioned index.

DROP INDEX needs to lock the index's table before the index itself,
else it will deadlock against ordinary queries that acquire the
relation locks in that order.  This is correctly mechanized for
plain indexes by RangeVarCallbackForDropRelation; but in the case of
a partitioned index, we neglected to lock the child tables in advance
of locking the child indexes.  We can fix that by traversing the
inheritance tree and acquiring the needed locks in RemoveRelations,
after we have acquired our locks on the parent partitioned table and
index.

While at it, do some refactoring to eliminate confusion between
the actual and expected relkind in RangeVarCallbackForDropRelation.
We can save a couple of syscache lookups too, by having that function
pass back info that RemoveRelations will need.

Back-patch to v11 where partitioned indexes were added.

Jimmy Yih, Gaurab Dey, Tom Lane

Discussion: https://postgr.es/m/BYAPR05MB645402330042E17D91A70C12BD5F9@BYAPR05MB6454.namprd05.prod.outlook.com
src/backend/commands/tablecmds.c
src/test/isolation/expected/partition-drop-index-locking.out [new file with mode: 0644]
src/test/isolation/isolation_schedule
src/test/isolation/specs/partition-drop-index-locking.spec [new file with mode: 0644]