From c213647ab221c0e895c58d0822c5deacf703eeb5 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 cdc4e7f38..7e69ea697 100644 --- a/src/backend/distributed/executor/multi_utility.c +++ b/src/backend/distributed/executor/multi_utility.c @@ -1331,8 +1331,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);