github-actions[bot] commented on code in PR #66913:
URL: https://github.com/apache/doris/pull/66913#discussion_r3978661740


##########
fe/fe-core/src/main/java/org/apache/doris/datasource/iceberg/source/IcebergScanNode.java:
##########
@@ -1764,20 +1880,11 @@ private Table useFrozenTableGeneration(Table 
currentTable) {
         if 
(snapshot.filter(IcebergMvccSnapshot.class::isInstance).isPresent()) {
             IcebergSnapshotCacheValue cacheValue =
                     ((IcebergMvccSnapshot) 
snapshot.get()).getSnapshotCacheValue();
+            frozenEnableMappingVarbinary = 
cacheValue.isEnableMappingVarbinary();
+            frozenEnableMappingTimestampTz = 
cacheValue.isEnableMappingTimestampTz();
             Optional<Table> frozenTable = cacheValue.getIcebergTable();
             if (frozenTable.isPresent()) {
-                // Planning the frozen generation (regular relations and 
snapshot-selectable
-                // system tables alike) uses the catalog's current 
authenticator, storage state
-                // and pre-authenticated executor. Those are only coherent 
with the retained
-                // frozen operations/FileIO while the catalog still serves the 
generation this
-                // statement pinned; after a credential/storage ALTER the 
statement must fail and
-                // be retried. Count-mode values retain no frozen handle and 
plan the live table,
-                // so they are not fenced; values without a captured context 
resolve nothing here.
-                if (cacheValue.getCapturedAuthenticator() != null) {
-                    cacheValue.ensurePlannableUnder(
-                            source.getCatalog().getExecutionAuthenticator(),
-                            source.getTargetTable().getName());
-                }
+                runtimeContext = cacheValue.getRuntimeContext();

Review Comment:
   [P1] Keep manifest-cache writes on this frozen generation
   
   Restoring G1's runtime here now deliberately lets this scan continue after 
an ALTER/reset, but `loadFileScanTasksWithManifestCache()` later resolves 
`ExtMetaCacheMgr.iceberg(source.getCatalog().getId())`, i.e. the live G2 cache 
group, while loading through this frozen G1 table/FileIO. Since 
`IcebergManifestEntryKey` contains only manifest path and content type, a scan 
paused across an endpoint/storage remap can publish G1 data/delete entries into 
G2, and a later G2 scan of the same URI will hit the wrong payload. Please 
carry the exact manifest-entry generation with the retained runtime (or 
suppress publication once it is no longer current), and cover an endpoint-A to 
endpoint-B reset barrier.



-- 
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]

Reply via email to