Fix race condition between DROP_RANGE and committing existing block#56083
Fix race condition between DROP_RANGE and committing existing block#56083
Conversation
|
This is an automated comment for commit ae8d7a5 with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page Successful checks
|
alexey-milovidov
left a comment
There was a problem hiding this comment.
Ok. Interesting if writing a test that could reproduce it even occasionally will be possible.
| storage.checkPartChecksumsAndAddCommitOps(zookeeper, part, ops, existing_part_name, unused); | ||
|
|
||
| /// We have to check that the block_id still exists to avoid a race condition with DROP_RANGE | ||
| block_unlock_op_idx = ops.size(); |
There was a problem hiding this comment.
I understand that we should update the exception message in:
else if (multi_code == Coordination::Error::ZNONODE && zkutil::getFailedOpIndex(multi_code, responses) == block_unlock_op_idx)
{
throw Exception(ErrorCodes::QUERY_WAS_CANCELLED,
"Insert query (for block {}) was cancelled by concurrent ALTER PARTITION", block_number_lock->getPath());
}
And instead of ALTER PARTITION it should say "operation" or something more generic, right?
There was a problem hiding this comment.
And instead of ALTER PARTITION it should say "operation" or something more generic, right?
It can be canceled by ALTER PARTITION or TRUNCATE (which is basically DROP PARTITION for all partitions). But a part can be removed from zk as a result of a merge, for example. And looks like in rare cases it may trigger this message too after my changes
|
Integration tests (asan) [1/6] - docker issue |
Changelog category (leave one):
Fixes #56037