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

Merge pull request #56 from amitlan/issue-55-fix

Browse Source 
Make repack_drop() processing robust against deadlocks.
This commit is contained in:
Josh Kupershmidt 2015-12-02 23:58:48 -05:00
commit 2b3a026372
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
lib/repack.c
View File

@ -949,6 +949,28 @@ repack_drop(PG_FUNCTION_ARGS)
/* connect to SPI manager */ /* connect to SPI manager */
repack_init(); repack_init();
/*
* 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.
*/
execute_with_format(
SPI_OK_UTILITY,
"LOCK TABLE %s.%s IN ACCESS EXCLUSIVE MODE",
nspname, relname);
/* drop log table: must be done before dropping the pk type, /* drop log table: must be done before dropping the pk type,
* since the log table is dependent on the pk type. (That's * since the log table is dependent on the pk type. (That's
* why we check numobj > 1 here.) * why we check numobj > 1 here.)