Summary

BlockIO::operator=(BlockIO&&) was not moving query_metadata_cache, causing the cache to be destroyed prematurely on every query through both TCP and HTTP paths.

Closes #95742

Root Cause Analysis

Bug #1: BlockIO::operator= does NOT move query_metadata_cache

In src/QueryPipeline/BlockIO.cpp:26-44:

BlockIO & BlockIO::operator= (BlockIO && rhs) noexcept
{
    reset();
    process_list_entries    = std::move(rhs.process_list_entries);
    pipeline                = std::move(rhs.pipeline);
    finalize_query_pipeline = std::move(rhs.finalize_query_pipeline);
    finish_callbacks        = std::move(rhs.finish_callbacks);
    exception_callbacks     = std::move(rhs.exception_callbacks);
    null_format             = rhs.null_format;
    // query_metadata_cache is NOT moved!
    return *this;
}

This is triggered on every query via both execution paths:

• TCP path (executeQuery.cpp:1970): res = executeQueryImpl(...)
• HTTP path (executeQuery.cpp:2168): streams = executeQueryImpl(...)

The consequence: executeQueryImpl packs the cache into its returned BlockIO, but operator= strips it out. The temp BlockIO is destroyed immediately, destroying the cache while the pipeline lives on in res.

What happens when the cache is destroyed prematurely

For mutation validation queries (ALTER TABLE ... UPDATE):

1. MutationsInterpreter::validate() builds a validation pipeline internally, which caches a StorageSnapshotPtr via getStorageSnapshot in the QueryMetadataCache
2. validate() returns — its internal pipeline is destroyed, releasing its StorageSnapshotPtr
3. The cache entry is now the ONLY remaining StorageSnapshotPtr (refcount = 1)
4. InterpreterAlterQuery::execute() returns an empty BlockIO (no pipeline)
5. executeQueryImpl packs the cache into the returned BlockIO
6. res = executeQueryImpl(...) → operator= moves the pipeline (empty) but NOT the cache
7. The temp BlockIO is destroyed → cache destroyed → last StorageSnapshotPtr released
8. ~StorageSnapshot → ~SnapshotData:
   • parts released → parts freed → clearCaches() → accesses storage

Why SnapshotData::storage doesn't always save us

Within SnapshotData destruction, parts (line 623) is freed before storage (line 619). So normally the storage IS alive when clearCaches runs.

But there's a complicating factor: MergeTreeData::shared_ranges_in_parts (line 1496) may hold the same RangesInDataPartsPtr. When both SnapshotData::parts and shared_ranges_in_parts share the same shared_ptr, the destruction chain becomes:

1. SnapshotData::parts released → refcount 2→1 (not freed, shared_ranges_in_parts still holds it)
2. SnapshotData::storage released → if table was DETACHED, this is the last ref → MergeTreeData destructor runs
3. During ~MergeTreeData(), shared_ranges_in_parts (line 1496) is destroyed → parts freed → clearCaches() → accesses this (the MergeTreeData being destroyed)

At this point we're inside MergeTreeData's destructor. The StorageMergeTree/StorageReplicatedMergeTree destructor has already run (derived class destructors run first). If shutdown() invalidated any state that clearCaches depends on (like context caches, virtual table pointers after derived destructor), this could SEGFAULT.

Bug #2: InterpreterOptimizeQuery mutably modifies cached snapshot

In src/Interpreters/InterpreterOptimizeQuery.cpp:81-82:

if (auto * snapshot_data = dynamic_cast<MergeTreeData::SnapshotData *>(storage_snapshot->data.get()))
    snapshot_data->parts = {};

This clears parts on a cached StorageSnapshot via a mutable cast, while storage remains set. This is a data race on shared state and could cause parts to be freed unexpectedly.

Historical context

Azat Khuzhin attempted a different fix in Jan 2026:

• 1002f7ce907 — Removed SnapshotData::storage, added BlockIO::resetPipeline() to destroy cache before pipeline
• d02700909db — Reordered BlockIO fields to match
• 8c44f5e9374 — Reverted both, putting SnapshotData::storage back

The revert restored the status quo, but the BlockIO::operator= bug (which predates all this) was never fixed.

Changelog category:

• Critical Bug Fix (crash, data loss, RBAC) or LOGICAL_ERROR

Changelog entry:

Fix crash (SEGFAULT) in clearCaches caused by BlockIO::operator= not moving query_metadata_cache, leading to premature destruction of cached storage snapshots and use-after-free of MergeTreeData storage.

🤖 Generated with Claude Code