github-actions[bot] commented on code in PR #69761:
URL: https://github.com/apache/doris/pull/69761#discussion_r4482667291
##########
fe/fe-core/src/main/java/org/apache/doris/cloud/alter/CloudSchemaChangeHandler.java:
##########
@@ -158,6 +159,12 @@ public void updateTableProperties(Database db, String
tableName, Map<String, Str
}
olapTable.readLock();
try {
+ // New partitions must retain the format required by the
table's values indexes.
+ if (invertedIndexFileStorageFormat !=
TInvertedIndexFileStorageFormat.SNII
Review Comment:
[P1] Recheck the values-index format under the mutation lock
With cloud partition-format rollout enabled, start with an SNII table
without a values index. Session A can pass this check for `SET
("partition.inverted_index_storage_format"="V2")`, release the read lock at
line 174, and pause. Session B can then complete a new-data-only values-index
ADD: `SchemaChangeHandler.processAddIndex()` verifies that all current/future
formats are still SNII. When A resumes, the final write lock at line 426 only
protects `modifyTableProperties()`; it never rechecks the new index. Both
statements succeed, and subsequently added partitions receive V2 tablets
carrying an SNII-only values index, whose writes violate the SNII writer's
format precondition. This is a concurrent bypass of the fixed sequential case
in discussion 4421823997. Revalidate the index/format invariant while holding
the final write lock, and cover this interleaving with a deterministic
concurrency test.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/info/IndexDefinition.java:
##########
@@ -380,6 +385,8 @@ public void checkColumn(Column column, KeysType keysType,
boolean enableUniqueKe
}
if (indexType == IndexType.INVERTED) {
+
validateVariantValuesIndex(DataType.fromCatalogType(column.getType()),
Review Comment:
[P2] Reject analyzer-based values-index ADD on MOR tables
On an existing SNII `UNIQUE KEY` table with `v VARIANT` and
`enable_unique_key_merge_on_write=false`, enabling new-data-only ADD allows
`ALTER TABLE t ADD INDEX vi(v) USING INVERTED
PROPERTIES("variant_index_scope"="values","analyzer"="english")`. This
catalog-column overload's preceding MOR guard checks only the `parser` key, so
the newly added values validation accepts this analyzer-only form; the CREATE
overload correctly rejects it. The resulting index cannot serve value-column
root MATCH filters because
`OlapScanLocalState::_should_push_down_common_expr()` retains them above MOR
merging. With `enable_match_without_inverted_index=false`, such queries fail
because the residual MATCH predicate is disabled, despite the accepted index.
Enforce the values-index table-model restriction for ADD/CREATE INDEX as well,
and add an analyzer-based MOR rejection test.
--
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]
