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

Make repack_drop() processing robust against deadlocks.

Browse Source 
Concurrent activity on the target table can cause deadlocks when
repack_drop() is doing its job, ie, dropping the temporary objects
created. It is highly likely to occur when pg_repack is interrupted
midway through its processing.
This commit is contained in:
amit 2015-11-06 17:10:13 +09:00
parent 20a679b7fb
commit 5317f527f4
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
lib/repack.c
View File

@ -949,6 +949,17 @@ 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.
*
* Fixes deadlock mentioned in the Github issue #55.
*/
execute_with_format(
SPI_OK_UTILITY,
"LOCK TABLE %s IN ACCESS EXCLUSIVE MODE",
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.)