github-actions[bot] commented on code in PR #66788:
URL: https://github.com/apache/doris/pull/66788#discussion_r3788217232
##########
fe/fe-core/src/main/java/org/apache/doris/qe/SessionVariable.java:
##########
@@ -3513,6 +3515,10 @@ public void
checkAnnIndexCandidateRowsPercentThreshold(String value) {
description = "Enable extended regular expressions, support
look-around zero-width assertions")
public boolean enableExtendedRegex = false;
+ @VarAttrDef.VarAttr(name = ENABLE_HYPERSCAN_FALLBACK, needForward = true,
affectQueryResultInExecution = true,
Review Comment:
[P2] Preserve strict mode across mixed-FE forwarding
Doris's [supported upgrade
order](https://doris.apache.org/docs/4.x/admin-manual/cluster-management/upgrade/)
leaves the master FE old while followers are already new. If a client sets
this to `false` on an upgraded follower and runs a normal INSERT containing
`REGEXP 'a{51}'`, the follower forwards the new map key, but the old master's
`setForwardedSessionVariables()` iterates only fields it knows and silently
ignores it. The old master then plans for the already-upgraded BEs without
field 231, so they restore the default `true` and fall back instead of
reporting the requested strict error. Fence forwarding on master capability (or
otherwise reject this setting during that mixed-FE window) and add
new-follower/old-master coverage. This is distinct from the existing same-line
point-query and load-planner threads because the value is lost at the FE-to-FE
boundary.
##########
fe/fe-core/src/main/java/org/apache/doris/planner/GroupCommitPlanner.java:
##########
@@ -123,7 +123,8 @@ public GroupCommitPlanner(Database db, OlapTable table,
List<String> targetColum
.setMergeType(TMergeType.APPEND).setThriftRpcTimeoutMs(5000).setLoadId(queryId)
.setTrimDoubleQuotes(true).setGroupCommitMode(groupCommit)
.setStrictMode(ConnectContext.get().getSessionVariable().enableInsertStrict);
- NereidsStreamLoadTask streamLoadTask =
NereidsStreamLoadTask.fromTStreamLoadPutRequest(streamLoadPutRequest);
+ NereidsStreamLoadTask streamLoadTask =
NereidsStreamLoadTask.fromTStreamLoadPutRequest(
+ streamLoadPutRequest,
ConnectContext.get().getSessionVariable().enableHyperscanFallback);
Review Comment:
[P2] Invalidate prepared group-commit plans for this option
This value is serialized into `execPlanFragmentParamsBytes` when the planner
is created, but `executeGroupCommitInsert()` reuses that planner whenever only
the table id and base schema version match. After a session executes a prepared
group-commit insert, changes `enable_hyperscan_fallback`, and executes it
again, BE-evaluated expressions (for example a generated column using `REGEXP
'a{51}'`) still receive the old policy. Store this option or the
execution-variable digest on the planner and include it in the reuse fence,
with a prepared group-commit regression that changes the setting between
executions. This is distinct from the existing point-query thread because it is
the separate `PreparedStatementContext.groupCommitPlanner` cache.
##########
fe/fe-core/src/main/java/org/apache/doris/load/StreamLoadHandler.java:
##########
@@ -269,7 +270,8 @@ public void generatePlan(OlapTable table) throws
UserException {
"get table read lock timeout, database=" + request.getDb()
+ ",table=" + table.getName());
}
try {
- NereidsStreamLoadTask streamLoadTask =
NereidsStreamLoadTask.fromTStreamLoadPutRequest(request);
+ NereidsStreamLoadTask streamLoadTask =
NereidsStreamLoadTask.fromTStreamLoadPutRequest(
+ request,
VariableMgr.getDefaultSessionVariable().enableHyperscanFallback);
Review Comment:
[P2] Read the RPC stream policy from the request snapshot
`defaultSessionVariable` is protected by `VariableMgr.rwlock`: `SET GLOBAL`
writes its plain fields under `wlock`, and request contexts clone it under
`rlock`. This line instead dereferences the live object without that lock after
the request snapshot already exists, so a concurrent `SET GLOBAL` can race with
planning and make one request nondeterministically use either policy. Read the
value from the request `ConnectContext` (or through a locked scalar accessor)
and cover an overlapping global update versus stream-plan creation with
latches/barriers. This is distinct from the existing load-propagation thread,
which covered the logical source but not its synchronized capture.
--
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]