englefly commented on code in PR #69028:
URL: https://github.com/apache/doris/pull/69028#discussion_r4355526082
##########
fe/fe-core/src/main/java/org/apache/doris/statistics/repository/StatisticsCleaner.java:
##########
@@ -140,6 +140,8 @@ private void clearTableStats() {
}
LOG.info("Table {}.{}.{} with id {} not exist, remove its
table stats record.",
stats.ctlName, stats.dbName, stats.tblName, id);
+ // No table lock: the table is gone, so no load can recreate
the record of this id while the
Review Comment:
已在 4c792cff11f 修复。
cleaner 现在对“还在回收站里”的表，会取**该回收站表对象的表写锁**（`RECOVER TABLE` 注册回的就是同一个实例，也正是 load
在 `finishTransaction` 里一直持有到记录重建完成的那把锁），把「删除记录 + 写 `DELETE_TABLE_STATS`
journal」放进同一个临界区，并在锁内重新查一次 catalog：
- 删除落在 RECOVER/LOAD 之前 → load 建记录对应的 journal 排在这次删除之后，重放顺序与 master 一致；
- load 已经建好记录 → 删掉的就是这条新记录，重放时同样会删掉 → 两边一致；
- 如果在检查与加锁之间表被 RECOVER 回来 → 不再当孤儿，保留它的统计。
表彻底不在回收站（不可恢复）时仍保留原来的无锁删除，因为这种 id 之后不会有 load 再建记录。另外新增
`CatalogRecycleBin#getRecycledTable(long)` 暴露回收站里的实例。之前那句“表已经没了，不会有 load
重建记录，所以不需要表锁”的注释是错的：`RECOVER TABLE` 会用原 id 重新注册，“不在 catalog”并不等于“这个 id 不会再产生记录”。
测试：
-
`StatisticsCleanerTest#testRecycledTableStatsAreRemovedUnderTheTableLock`：删除与
journal 写严格落在 `writeLock` 与 `writeUnlock` 之间；
-
`StatisticsCleanerTest#testTableRecoveredBeforeTheRemovalKeepsItsStats`：锁内发现表已被恢复则不动记录、不写
journal；
- `StatisticsCleanerTest` 3/3，checkstyle 通过。
--
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]
