github-actions[bot] commented on code in PR #67622:
URL: https://github.com/apache/doris/pull/67622#discussion_r3953931824
##########
fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/UserProperty.java:
##########
@@ -223,8 +224,10 @@ public void update(List<Pair<String, String>> properties,
boolean isReplay) thro
throw new DdlException(PROP_MAX_USER_CONNECTIONS + " is
not number");
}
- if (newMaxConn <= 0 || newMaxConn > 10000) {
- throw new DdlException(PROP_MAX_USER_CONNECTIONS + " is
not valid, must between 1 and 10000");
+ long maxUserConnLimit = Math.max(Config.qe_max_connection,
10000);
Review Comment:
This replicated property cannot use only the current Master's FE-local
`qe_max_connection` as its durable bound. In an all-upgraded cluster with
Master A at 10000 and FE B at 20000, setting 15000 fails on A but succeeds
after B becomes Master, although each `ConnectPoolMgr` already safely enforces
`min(local global cap, user cap)`. Replay also diverges: a 20000-cap leader can
journal 15000, a 12000-cap follower throws here, and
`Auth.replayUpdateUserProperty` catches/logs the error while replay advances
and leaves the stale cap. Finally, gating replay in the new code is
insufficient because the base FE still rejects values above 10000 during
rolling upgrade/rollback. Please define a deterministic cluster-wide/type bound
for normal write and replay, add a backward-compatible activation fence for old
FEs, and test Master-identity independence, different-config replay, and
mixed-version activation.
--
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]
