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

Merge pull request #166 from bashtanov/fix_lockup

Browse Source 
Avoid excessive locking when table already being repacked by another instance
This commit is contained in:
Josh Kupershmidt 2018-03-21 14:35:33 -04:00 committed by GitHub
commit 02e6c5ce96
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
lib/repack.c
View File

@ -1007,11 +1007,21 @@ repack_drop(PG_FUNCTION_ARGS)
* which in turn, is waiting for lock on log_%u table. * which in turn, is waiting for lock on log_%u table.
* *
* Fixes deadlock mentioned in the Github issue #55. * Fixes deadlock mentioned in the Github issue #55.
*
* Skip the lock if we are not going to do anything.
* Otherwise, if repack gets accidentally run twice for the same table
* at the same time, the second repack, in order to perform
* a pointless cleanup, has to wait until the first one completes.
* This adds an ACCESS EXCLUSIVE lock request into the queue
* making the table effectively inaccessible for any other backend.
*/ */
if (numobj > 0)
{
execute_with_format( execute_with_format(
SPI_OK_UTILITY, SPI_OK_UTILITY,
"LOCK TABLE %s.%s IN ACCESS EXCLUSIVE MODE", "LOCK TABLE %s.%s IN ACCESS EXCLUSIVE MODE",
nspname, relname); 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