github-actions[bot] commented on code in PR #65219:
URL: https://github.com/apache/doris/pull/65219#discussion_r3528120739
##########
fe/fe-core/src/main/java/org/apache/doris/clone/DynamicPartitionScheduler.java:
##########
@@ -296,23 +335,29 @@ private ArrayList<AddPartitionOp>
getAddPartitionOp(Database db, OlapTable olapT
int hotPartitionNum = dynamicPartitionProperty.getHotPartitionNum();
String storagePolicyName = dynamicPartitionProperty.getStoragePolicy();
+ // Partition naming uses the same `now` clock as border computation,
+ // so names and values are based on the same timezone (UTC for
TIMESTAMPTZ).
String nowPartitionPrevBorder =
DynamicPartitionUtil.getPartitionRangeString(
dynamicPartitionProperty, now, 0, partitionFormat);
String nowPartitionName = dynamicPartitionProperty.getPrefix()
- +
DynamicPartitionUtil.getFormattedPartitionName(dynamicPartitionProperty.getTimeZone(),
+ +
DynamicPartitionUtil.getFormattedPartitionName(borderTimeZone,
nowPartitionPrevBorder,
dynamicPartitionProperty.getTimeUnit());
+ // UTC-based lower bound of the current partition, used to identify the
+ // current partition by range in getHistoricalPartitions().
+ String currentUtcBorder = DynamicPartitionUtil.getPartitionRangeString(
+ dynamicPartitionProperty, now, 0, partitionFormat);
+ currentUtcBorder = convertToUtcTimestamp(partitionColumn,
currentUtcBorder, borderTimeZone);
for (; idx <= dynamicPartitionProperty.getEnd(); idx++) {
+ // Borders for both partition values and names: use now.
String prevBorder = DynamicPartitionUtil.getPartitionRangeString(
dynamicPartitionProperty, now, idx, partitionFormat);
String nextBorder = DynamicPartitionUtil.getPartitionRangeString(
dynamicPartitionProperty, now, idx + 1, partitionFormat);
- // Save original border for partition name (must not contain UTC
suffix)
+ // Save pre-conversion border for naming (UTC-based for
TIMESTAMPTZ).
String prevBorderForName = prevBorder;
- prevBorder = convertToUtcTimestamp(partitionColumn, prevBorder,
- dynamicPartitionProperty.getTimeZone());
- nextBorder = convertToUtcTimestamp(partitionColumn, nextBorder,
- dynamicPartitionProperty.getTimeZone());
+ prevBorder = convertToUtcTimestamp(partitionColumn, prevBorder,
borderTimeZone);
Review Comment:
Existing tables that have already been scheduled by the old code can get
stuck on the shifted layout. The old TIMESTAMPTZ path with
`dynamic_partition.time_zone = 'Asia/Shanghai'` persisted daily ranges such as
`[2026-07-05 16:00:00+00:00, 2026-07-06 16:00:00+00:00)`. After this PR, the
same table tries to add `[2026-07-06 00:00:00+00:00, 2026-07-07
00:00:00+00:00)`. This loop checks every existing range with
`RangeUtils.checkRangeIntersect`; because the old range partially overlaps but
is not equal, the catch records a create failure, sets `isPartitionExists`, and
skips the new partition. The same happens while old future partitions overlap
the new UTC candidates, and when the first non-overlapping UTC partition is
finally added there can be a gap between the last old `16:00` upper bound and
the next UTC midnight. Please add an explicit upgrade/compatibility path, or a
migration test that starts from pre-fix offset-aligned TIMESTAMPTZ ranges and
verifies scheduler behavior after
the UTC change.
##########
fe/fe-core/src/main/java/org/apache/doris/clone/DynamicPartitionScheduler.java:
##########
@@ -373,22 +418,22 @@ private ArrayList<AddPartitionOp>
getAddPartitionOp(Database db, OlapTable olapT
}
// set storage_medium and storage_cooldown_time based on
dynamic_partition.hot_partition_num
- setStorageMediumProperty(partitionProperties,
dynamicPartitionProperty, now, hotPartitionNum, idx);
+ setStorageMediumProperty(partitionProperties,
dynamicPartitionProperty, nowTz, hotPartitionNum, idx);
Review Comment:
After changing TIMESTAMPTZ partition ranges and names to use UTC, this path
still derives hot-partition cooldown and dynamic storage-policy
`data_base_time_ms` from `nowTz`, the configured time zone. That can put
lifecycle timestamps on a different calendar bucket than the partition being
created. For example, with a daily TIMESTAMPTZ table,
`dynamic_partition.time_zone = 'America/Chicago'`, `hot_partition_num = 1`, and
a run at `2026-07-06 03:00:00 UTC`, the current partition is `[2026-07-06
00:00:00+00:00, 2026-07-07 00:00:00+00:00)`, but `setStorageMediumProperty(...,
nowTz, idx=0)` formats `offset + hotPartitionNum` from Chicago's previous local
day and produces `2026-07-06 00:00:00` as the cooldown time, before that UTC
partition has ended. The storage-policy `data_base_time_ms` on the next line
has the same mismatch. Please derive these storage lifecycle timestamps from
the same UTC clock/borders used for TIMESTAMPTZ partition ranges, or explicitly
convert them to the intend
ed absolute UTC boundary, and add a non-UTC TIMESTAMPTZ test covering
`hot_partition_num` or storage policy.
--
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]
