From 27171c230ca2388a1fbba229fa33091358d2fae8 Mon Sep 17 00:00:00 2001 From: Jason Petersen Date: Thu, 4 Aug 2016 13:49:51 -0700 Subject: [PATCH] Avoid attempting to lock invalid shard identifier A recent change generates a "dummy" shard placement with its identifier set to INVALID_SHARD_ID for SELECT queries against distributed tables with no shards. Normally, no lock is acquired for SELECT statements, but if all_modifications_commutative is set to true, we will acquire a shared lock, triggering an assertion failure within LockShardResource in the above case. The "dummy" shard placement is actually necessary to ensure such empty queries have somewhere to execute, and INVALID_SHARD_ID seems the most appropriate value for the dummy's shard identifier field, so the most straightforward fix is to just avoid locking invalid shard identifiers. --- src/backend/distributed/executor/multi_router_executor.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/backend/distributed/executor/multi_router_executor.c b/src/backend/distributed/executor/multi_router_executor.c index d82526f46..8038feb18 100644 --- a/src/backend/distributed/executor/multi_router_executor.c +++ b/src/backend/distributed/executor/multi_router_executor.c @@ -294,7 +294,10 @@ AcquireExecutorShardLock(Task *task, LOCKMODE lockMode) { int64 shardId = task->anchorShardId; - LockShardResource(shardId, lockMode); + if (shardId != INVALID_SHARD_ID) + { + LockShardResource(shardId, lockMode); + } }