github-actions[bot] commented on code in PR #64314:
URL: https://github.com/apache/doris/pull/64314#discussion_r3381706899
##########
fe/fe-core/src/main/java/org/apache/doris/qe/RuntimeFilterTypeHelper.java:
##########
@@ -42,8 +42,7 @@ public class RuntimeFilterTypeHelper {
public static final long ALLOWED_MASK = (TRuntimeFilterType.IN.getValue()
| TRuntimeFilterType.BLOOM.getValue()
| TRuntimeFilterType.MIN_MAX.getValue()
- | TRuntimeFilterType.IN_OR_BLOOM.getValue()
- | TRuntimeFilterType.BITMAP.getValue());
+ | TRuntimeFilterType.IN_OR_BLOOM.getValue());
private static final Map<String, Long> varValueSet =
Maps.newTreeMap(String.CASE_INSENSITIVE_ORDER);
Review Comment:
Separate from the existing planner-enumeration thread, this also breaks
upgrade/replay of persisted `runtime_filter_type` values.
`GlobalVarPersistInfo` stores the raw numeric field, and replay goes through
`VariableMgr.replayGlobalVariableV2 -> setValue ->
RuntimeFilterTypeHelper.encode(root value)`. If an existing cluster had `SET
GLOBAL runtime_filter_type='IN_OR_BLOOM_FILTER,BITMAP_FILTER'` (24), or that
plus `MIN_MAX` (28), this new mask makes `encode("24")`/`encode("28")` throw;
replay catches and ignores the whole variable, so the non-deprecated bits are
silently lost. `SHOW VARIABLES` has a similar decode failure path for sessions
that still contain bit 16. Please add a compatibility path that strips the
deprecated BITMAP bit from persisted/numeric values while still rejecting new
`BITMAP_FILTER` user input, and cover it with a 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]
