From ab509db0d86b28abbbaa4475d8b590095218b55c Mon Sep 17 00:00:00 2001 From: Burak Yucesoy Date: Mon, 10 Jul 2017 13:55:34 +0300 Subject: [PATCH] Use ShareUpdateExclusiveLock instead ShareLock in VACUUM Before this change, we used ShareLock to acquire lock on distributed tables while running VACUUM. This makes VACUUM and INSERT block each other. With this change we changed lock mode from ShareLock to ShareUpdateExclusiveLock, which does not conflict with the locks INSERT acquire. --- src/backend/distributed/executor/multi_utility.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/backend/distributed/executor/multi_utility.c b/src/backend/distributed/executor/multi_utility.c index c4af3de3a..3009c0f41 100644 --- a/src/backend/distributed/executor/multi_utility.c +++ b/src/backend/distributed/executor/multi_utility.c @@ -1248,8 +1248,13 @@ VacuumTaskList(Oid relationId, VacuumStmt *vacuumStmt) char *schemaName = get_namespace_name(schemaId); char *tableName = get_rel_name(relationId); - /* lock relation metadata before getting shard list */ - LockRelationDistributionMetadata(relationId, ShareLock); + /* + * We obtain ShareUpdateExclusiveLock here to not conflict with INSERT's + * RowExclusiveLock. However if VACUUM FULL is used, we already obtain + * AccessExclusiveLock before reaching to that point and INSERT's will be + * blocked anyway. This is inline with PostgreSQL's own behaviour. + */ + LockRelationOid(relationId, ShareUpdateExclusiveLock); shardIntervalList = LoadShardIntervalList(relationId);