github-actions[bot] commented on code in PR #68282:
URL: https://github.com/apache/doris/pull/68282#discussion_r4078713416
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/InternalCatalog.java:
##########
@@ -3904,7 +3904,7 @@ public void truncateTable(String dbName, String
tableName, PartitionNamesInfo pa
oldPartitions = truncateTableInternal(olapTable, newPartitions,
truncateEntireTable, recyclePartitionParamMap, forceDrop,
version, versionTimeMs);
if (truncateEntireTable) {
-
Env.getCurrentEnv().getAnalysisManager().removeTableStats(olapTable.getId());
+
Env.getCurrentEnv().getAnalysisManager().resetTableStats(olapTable);
Review Comment:
The retained reset is not ordered with existing stats-record deletions. For
example, TRUNCATE can reset here, concurrent whole-table `DROP STATS` (which
takes no table lock) can remove the record and journal `OP_DELETE_TABLE_STATS`,
and then TRUNCATE journals `OP_TRUNCATE_TABLE`. The master ends absent, but
replay applies DELETE then `replayTruncateTable()` recreates the record; the
trailing stats snapshot is absent because the map is null. Empty-table auto
cleanup has the same ordering, and `SchemaChangeJobV2` can remove stats after
its FINISHED journal and unlock. Subsequent row events can therefore be dropped
on the master but retained after replay/failover. Before this change these
delete/reset transitions commuted. Please coordinate all record-deletion/reset
transitions with their journal order (or make them generation-aware) and add a
deterministic replay-order 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]
