github-actions[bot] commented on code in PR #63884:
URL: https://github.com/apache/doris/pull/63884#discussion_r3340276062
##########
fe/fe-core/src/main/java/org/apache/doris/qe/ConnectContext.java:
##########
@@ -369,6 +371,46 @@ public void clearLastDBOfCatalog() {
lastDBOfCatalog.clear();
}
+ public void resetConnection() throws UserException {
+ closeTxnForConnectionReset();
+ if (!dbToTempTableNamesMap.isEmpty()) {
+ cleanupTemporaryTables(true);
+ dbToTempTableNamesMap.clear();
+ }
+ resetSessionVariable();
+ userVars = new HashMap<>();
+ preparedQuerys.clear();
+ preparedStatementContextMap.clear();
+ preparedStmtId = INITIAL_PREPARED_STMT_ID;
+ runningQuery = null;
+ resetQueryId();
Review Comment:
`resetQueryId()` preserves the old current query by copying it into
`lastQueryId`, so after `COM_RESET_CONNECTION` a fresh session can still run
`select last_query_id()` and see the query executed before the reset. This is
distinct from the processlist `queryId` cleanup: `last_query_id()` reads
`ConnectContext.lastQueryId` through `FoldConstantRuleOnFE`, and this call
intentionally populates it. Please clear `lastQueryId` as part of connection
reset (for example after clearing the current query id) so query identity state
matches a new session.
##########
fe/fe-core/src/main/java/org/apache/doris/qe/ConnectContext.java:
##########
@@ -369,6 +371,46 @@ public void clearLastDBOfCatalog() {
lastDBOfCatalog.clear();
}
+ public void resetConnection() throws UserException {
+ closeTxnForConnectionReset();
+ if (!dbToTempTableNamesMap.isEmpty()) {
+ cleanupTemporaryTables(true);
+ dbToTempTableNamesMap.clear();
+ }
+ resetSessionVariable();
+ userVars = new HashMap<>();
+ preparedQuerys.clear();
+ preparedStatementContextMap.clear();
+ preparedStmtId = INITIAL_PREPARED_STMT_ID;
Review Comment:
Resetting `preparedStmtId` makes old client-side statement handles able to
collide with new server-side statements created after `COM_RESET_CONNECTION`. A
concrete sequence is: prepare `select 1` and get id `Integer.MIN_VALUE`, send
`COM_RESET_CONNECTION` (map cleared and id reset here), prepare `select 2` and
get the same id, then execute the stale first `ServerPreparedStatement`; the
server finds that id in `preparedStatementContextMap` and executes the new
statement instead of returning `ERR_UNKNOWN_STMT_HANDLER`. Please keep the
statement id counter monotonic across reset while clearing only the statement
map, so stale handles cannot become valid again within the same connection.
--
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]
