github-actions[bot] commented on code in PR #66255:
URL: https://github.com/apache/doris/pull/66255#discussion_r3689462964
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/InternalCatalog.java:
##########
@@ -3771,9 +3771,11 @@ private List<Partition> truncateTableInternal(OlapTable
olapTable, List<Partitio
olapTable.dropPartitionForTruncate(olapTable.getDatabase().getId(),
isforceDrop, pair.getValue());
}
- // Reset table-level visibleVersion to TABLE_INIT_VERSION so it stays
consistent
- // with the newly created partitions (which also start at
PARTITION_INIT_VERSION).
- olapTable.resetVisibleVersion();
+ // Truncate changes visible data without changing the table ID. Keep
the table version
+ // monotonic so snapshot consumers cannot mistake new data for an old
version.
+ if (Config.isNotCloudMode()) {
+ olapTable.updateVisibleVersionAndTime(olapTable.getNextVersion(),
System.currentTimeMillis());
Review Comment:
[P1] Make the new transition replay-compatible
`TruncateTableInfo` still carries no table version or transition marker, so
mixed FE versions interpret the same journal record differently: this code
advances `V -> V+1`, while an old follower's replay still calls
`resetVisibleVersion()` and records 1. If that follower is promoted, subsequent
loads can climb back to an MTMV snapshot version and recreate the ABA miss this
change is meant to remove. A new follower replaying an old truncate also
reconstructs different metadata. Persist version/time in the log (as
drop/replace partition do), preserve legacy replay for old records, and gate
emitting the new transition until electable FEs understand it.
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/InternalCatalog.java:
##########
@@ -3771,9 +3771,11 @@ private List<Partition> truncateTableInternal(OlapTable
olapTable, List<Partitio
olapTable.dropPartitionForTruncate(olapTable.getDatabase().getId(),
isforceDrop, pair.getValue());
}
- // Reset table-level visibleVersion to TABLE_INIT_VERSION so it stays
consistent
- // with the newly created partitions (which also start at
PARTITION_INIT_VERSION).
- olapTable.resetVisibleVersion();
+ // Truncate changes visible data without changing the table ID. Keep
the table version
+ // monotonic so snapshot consumers cannot mistake new data for an old
version.
+ if (Config.isNotCloudMode()) {
Review Comment:
[P1] Preserve a post-swap invalidation in Cloud mode
Cloud publishes/caches the MS version in `afterCreatePartitions()` before
this helper swaps local partitions. A concurrent SimpleAgg load can therefore
read the old partitions while stamping its result with `(newVersion,
oldVisibleVersionTime)`. Since this branch no longer changes either token after
the swap, that stale count/min/max remains a valid cache hit after `TRUNCATE`.
The same problem occurs if an idempotent `commit_partition` retry returns no
`table_version`. The previous unconditional reset changed local version time at
the swap and fenced these entries. Please retain a synchronous local cache
generation/invalidation here for Cloud as well, while leaving the authoritative
version MS-managed.
##########
regression-test/suites/mtmv_p0/test_truncate_table_mtmv.groovy:
##########
@@ -71,6 +86,18 @@ suite("test_truncate_table_mtmv","mtmv") {
REFRESH MATERIALIZED VIEW ${mvName} AUTO
"""
waitingMTMVTaskFinishedByMvName(mvName)
+
+ // Save a non-PCT table snapshot at version 3 while the MV does not
contain k2=2.
Review Comment:
[P2] Keep the PCT truncate assertion before the COMPLETE refresh
This assertion used to run immediately after the AUTO refresh at lines
83-88. With it moved below this COMPLETE refresh, a broken PCT AUTO refresh can
do nothing; COMPLETE then rebuilds from the already-truncated fact table, and
the later assertion still produces the expected `(2,2),(3,3)`. This is the only
MTMV regression for base-table partition `TRUNCATE`. Keep an `order_qt`
immediately after the first wait and add a separately named assertion/output
entry for the new non-PCT ABA scenario.
--
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]
