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.
pull/706/head
Jason Petersen 2016-08-04 13:49:51 -07:00
parent ccc32f9da8
commit eba8396501
No known key found for this signature in database
GPG Key ID: 9F1D3510D110ABA9
1 changed files with 4 additions and 1 deletions

View File

@ -294,8 +294,11 @@ AcquireExecutorShardLock(Task *task, LOCKMODE lockMode)
{ {
int64 shardId = task->anchorShardId; int64 shardId = task->anchorShardId;
if (shardId != INVALID_SHARD_ID)
{
LockShardResource(shardId, lockMode); LockShardResource(shardId, lockMode);
} }
}
/* /*