airborne12 opened a new pull request, #66316:
URL: https://github.com/apache/doris/pull/66316
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
`TabletSchema::remove_index` rebuilds the `(index_type, col_unique_id,
index_suffix) -> position` lookup map after dropping an entry. The loop
walks each surviving index, but builds every map key from
`_indexes.back()` instead of the entry being registered:
```cpp
for (size_t new_pos = 0; new_pos < _indexes.size(); ++new_pos) {
const auto& index = _indexes[new_pos];
...
IndexKey key = std::make_tuple(_indexes.back()->index_type(), col_uid,
_indexes.back()->get_index_suffix());
_col_id_suffix_to_index[key].push_back(new_pos);
}
```
So every survivor is filed under the LAST survivor's index type and
suffix. When the survivors are homogeneous -- e.g. several INVERTED
indexes with no suffix, which is what the existing coverage uses -- every
key is identical and the result is accidentally correct. When they differ,
it is not: after dropping one of two INVERTED indexes on a table that also
carries an NGRAM_BF index, the surviving INVERTED index is filed under
`(NGRAM_BF, col, "")`, and `inverted_indexs()` -- which looks up
`IndexType::INVERTED` -- no longer finds it. A surviving index then becomes
invisible to callers that resolve indexes through this map, including the
segment writer and index compaction, with no error reported. The same
applies to indexes that differ only in suffix (variant sub-column indexes).
The fix keys each entry by its own `index_type()` / `get_index_suffix()`.
This also makes `remove_index` consistent with the other three sites that
populate the same map (`append_index`, `init_from_pb`, and the
column-append path): those iterate right after `_indexes.emplace_back(...)`,
where `_indexes.back()` IS the entry being registered, so they are correct
as written and are left unchanged.
The map is a runtime cache rebuilt from scratch by `init_from_pb`, so a
schema that round-trips through protobuf is unaffected; only an in-memory
schema that keeps being used after `remove_index` sees the stale mapping.
### Release note
None
### Check List (For Author)
- Test: Unit Test. Added
`TabletSchemaTest.test_remove_index_keeps_heterogeneous_survivors_findable`,
which drops one of two INVERTED indexes while an NGRAM_BF index remains
last and asserts the surviving INVERTED index is still returned by
`inverted_indexs()`. It fails before this change and passes after; the
whole `TabletSchema*` suite is green (39 tests).
- Behavior changed: No. This restores the intended lookup result; no
on-disk format or interface changes.
- Does this need documentation: No
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
