rangareddy commented on issue #16675: URL: https://github.com/apache/hudi/issues/16675#issuecomment-5434696223
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-8346). **Findings: confirmed not done, and there is a hardcoded `true` to point at.** The flag is fully plumbed. `HoodieMetadataPayload.java:157` defines `COLUMN_STATS_FIELD_IS_TIGHT_BOUND`, `:607` takes it as a parameter and `:632` sets it via `setIsTightBound`; `HoodieTableMetadataUtil.java:2123`, `:2127` and `:2139` thread it through. But the value is hardcoded at `HoodieTableMetadataUtil.java:2216`: ```java return collectAndProcessColumnMetadata(fileColumnMetadata, partitionPath, true, columnsToIndexSchemaMap, partitionStatsIndexVersion).iterator(); ``` So there is no path today that sets it `false` for a delete. Corroborating that the flag is known to be imprecise: `HoodieMetadataTableValidator.java:1073` carries `// TODO: fix isTightBound flag when stats based on log files are available`, and `:1047` sets it false for a different reason entirely. Your ask is narrow and well defined - the bound genuinely is not guaranteed accurate after a delete, and a reader trusting `isTightBound=true` there could prune a file it should have read. Worth noting that consequence on the ticket, since it makes this a correctness concern rather than a metadata nicety. -- 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]
