Doris-Breakwater commented on issue #66936: URL: https://github.com/apache/doris/issues/66936#issuecomment-5338825076
### Initial assessment This is a **high-confidence, known FE defect in 4.1.3**, not a missing dynamic-partition property in the supplied DDL. The issue currently has no labels; `bug` is appropriate. No new code change appears necessary unless the problem also reproduces on a build containing the existing 4.1 backport. ### Code-level evidence - The `4.1.3` tag predates the relevant fix. - In 4.1.3, `DynamicPartitionScheduler` generates suffix-free date strings and asks `PartitionKey` to convert them to `TIMESTAMPTZ`. The 4.1.3 conversion path directly reads `ConnectContext.get().getSessionVariable().timeZone`. - The first dynamic-partition pass is invoked synchronously from `CREATE TABLE`, where the SQL session context exists, so the initial partitions can be created. - Later passes run in the `DynamicPartitionScheduler` daemon thread, which has no SQL-session `ConnectContext`. The `TIMESTAMPTZ` bound conversion therefore fails. `getAddPartitionClause()` catches that failure for each candidate partition and continues without calling `recordCreatePartitionFailedMsg()`. This also explains the reported diagnostic gap: `SHOW DYNAMIC PARTITION TABLES` may show a recent scheduler time and `NORMAL`/no create error even though no new partition was generated. The detailed failure should only be visible in the master FE log. The maintained `branch-4.1` contains commit `e7e6a57996590eeb93881cf575df4b020e283712` via [PR #66292](https://github.com/apache/doris/pull/66292), backporting [PR #64795](https://github.com/apache/doris/pull/64795) and [PR #65219](https://github.com/apache/doris/pull/65219). That change removes the unsafe direct session-context access, generates explicit UTC (`+00:00`) boundaries for `TIMESTAMPTZ`, aligns partition names/ranges to UTC, and adds `TIMESTAMPTZ` dynamic-partition regression coverage. The commit is present on `branch-4.1` but is not contained in the `4.1.3` tag. ### Recommended next steps 1. Ask the reporter to validate the same DDL on a 4.1 build containing `e7e6a57996590eeb93881cf575df4b020e283712` (or a later official 4.1 release that contains it). Do not backport another implementation before that validation. 2. If it still reproduces there, request: - the exact `SHOW DYNAMIC PARTITION TABLES FROM inland_dwd` row after waiting longer than `dynamic_partition_check_interval_seconds`; - the master FE values of `dynamic_partition_enable` and `dynamic_partition_check_interval_seconds`; - master FE log lines around `Error in gen addPartitionKeyRange`, `date convert to datetime failed`, or `DynamicPartitionScheduler` for the affected table; - `SHOW CREATE TABLE inland_dwd.dwd_fact_game_online_dot` and the exact FE build/commit hash. 3. On 4.1.3, upgrading to a build containing the backport is the preferred remediation. A temporary operational workaround is to manage future partitions manually while dynamic partitioning is disabled, or to use `DATETIMEV2` only if losing `TIMESTAMPTZ` semantics is acceptable. 4. There is also an observability issue in 4.1.3: failures while constructing candidate partition ranges are logged but not propagated to the runtime status shown by `SHOW DYNAMIC PARTITION TABLES`. Track that separately if current code still has the same behavior. Breakwater-GitHub-Analysis-Slot: slot_1a2315b50daf -- 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]
