farrokhi/pg_repack
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Expand a comment in repack_drop().

Browse Source 
Previous text did not sufficiently explain why taking a lock on the
target table would be necessary.
This commit is contained in:
amit 2015-11-09 15:23:45 +09:00
parent 5317f527f4
commit 94232991b9
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
lib/repack.c
View File

@ -950,8 +950,19 @@ repack_drop(PG_FUNCTION_ARGS)
repack_init();
/*
* To prevent concurrent lockers of the repack target table from
* causing deadlocks, take an exclusive lock on it.
* To prevent concurrent lockers of the repack target table from causing
* deadlocks, take an exclusive lock on it. Consider that the following
* commands take exclusive lock on tables log_xxx and the target table
* itself when deleting the z_repack_trigger on it, while concurrent
* updaters require row exclusive lock on the target table and in
* addition, on the log_xxx table, because of the trigger.
*
* Consider how a deadlock could occur - if the DROP TABLE repack.log_%u
* gets a lock on log_%u table before a concurrent updater could get it
* but after the updater has obtained a lock on the target table, the
* subsequent DROP TRIGGER ... ON target-table would report a deadlock as
* it finds itself waiting for a lock on target-table held by the updater,
* which in turn, is waiting for lock on log_%u table.
*
* Fixes deadlock mentioned in the Github issue #55.
*/