Doris-Breakwater commented on issue #68896: URL: https://github.com/apache/doris/issues/68896#issuecomment-6098933692
Source inspection supports the repeated-retry concern, with one material correction: in the inspected upstream code, `huge_table_auto_analyze_interval_in_millis` is not consulted by the auto-analyze scheduling path. Recording a failed attempt alone would therefore not make this setting effective. I checked the official `4.1.4` tag (commit `ad35a140c7fd0b842f18c23300bac581f7d04326`) and current master (`dd456ab7a894f54c6553415223c6d5c9c7d4e035`). These findings are from read-only source inspection; I have not reproduced the workload or run a Doris cluster. Verified behavior: - When all tasks reach terminal states and any task failed, `AnalysisManager.updateTaskStatus()` marks the job failed and records its history, without calling `updateTableStats()`. `markFailed()` does record the **job's end time**; it does not advance the table's successful-analyze metadata. The failed-job `partitionUpdateRows` cleanup described here exists on current master; the official `4.1.4` tag does not have that cleanup in its failure branch. This distinction does not change retry eligibility. See [4.1.4 failure handling](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/statistics/AnalysisManager.java#L530-L560) and [master failure handling](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/statistics/analysis/AnalysisManager.java#L542-L579). - `TableStatsMeta.update()` sets `lastAnalyzeTime` to the successful job's **creation time**, while also updating column freshness, row counts, versions, and partition metadata. Calling this whole method for a failed job could incorrectly mark uncollected statistics as fresh. See [the metadata update](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/statistics/analysis/TableStatsMeta.java#L164-L217). - In `4.1.4`, `getHugeTableAutoAnalyzeIntervalInMillis()` exists but has no callers in the source tree. On inspected master, that getter is absent, while the [global variable and its minimum-interval description remain](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/qe/SessionVariable.java#L2824-L2828). The collector filters columns through `needAnalyzeColumn(...) || isLongTimeColumn(...)`, without a huge-table interval gate. See [the collector](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/statistics/analysis/StatisticsAutoCollector.java#L146-L186). - Missing column/table statistics and stale OLAP statistics remain eligible after failure. The appender can enqueue them again; its low-priority round has a one-minute minimum interval, and the collector uses `auto_check_statistics_in_minutes`. This supports repeated attempts, but does not establish the exact cadence or scan volume in this deployment. The time check against `lastAnalyzeTime` in `needAnalyzeColumn()` is for **external tables** and uses `external_table_auto_analyze_interval_in_millis`. See [eligibility checks](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/statistics/util/StatisticsUtil.java#L785-L857) and [re-enqueueing](https://github.com/apache/doris/blob/dd456ab7a894f54c6553415223c6d5c9c7d4e035/fe/fe-core/src/main/java/org/apache/doris/statistics/analysis/StatisticsJobAppender.java#L152-L219). Suggested maintainer direction: route this to FE statistics scheduling. Confirm whether the advertised huge-table interval is intended to remain supported. If so, implement an explicit scheduling gate alongside separate attempt/backoff state, preserving successful-statistics freshness. Check the gate before submitting scans so all priority paths, missing-statistics cases, and the `isLongTimeColumn()` alternative respect it. Specify whether the cooldown starts at submission or terminal failure, and how it behaves across FE restart/failover. Avoid fixing this by simply calling `updateTableStats()` on failure. Useful regression coverage would include first-ever analyze failure with no table metadata, failure with existing stale statistics, partial task success followed by failure, suppression before the cooldown expires, retry afterward, and successful recovery. The tests should assert that failures leave successful column/partition freshness unchanged. To confirm the deployed behavior, please provide: - Exact FE build/commit, table/catalog type, partitioning, approximate size, and actual SAMPLE/FULL method. Huge-table selection normally chooses SAMPLE; partition analysis can force FULL. - `SHOW AUTO ANALYZE <table>` for two or three consecutive failed SYSTEM jobs, including job IDs, start/end times, priority and messages; corresponding `SHOW ANALYZE TASK STATUS <job_id>`, FE error logs and query IDs; and `SHOW TABLE STATS <table>` before/after failure. - Effective global values for the huge-table interval/size threshold, `analyze_timeout`, `enable_partition_analyze`, auto-analyze window, and FE `auto_check_statistics_in_minutes`, plus reproducible setup steps. Background statistics queries use global `analyze_timeout`; changing an ordinary session's `query_timeout` does not establish this reproduction. The repeated-failure mechanism is supported by the code; timeout under load as the underlying scan failure remains unverified without those errors. The off-peak window is a reasonable interim mitigation because the collector and automatic task wrapper check it, although failures can still recur within the allowed window. Breakwater-GitHub-Analysis-Slot: slot_d826c38590e2 -- 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]
