github-actions[bot] commented on code in PR #66297:
URL: https://github.com/apache/doris/pull/66297#discussion_r3685102948
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/paimon/PaimonExternalTable.java:
##########
@@ -248,7 +263,11 @@ public BaseAnalysisTask createAnalysisTask(AnalysisInfo
info) {
public long fetchRowCount() {
makeSureInitialized();
long rowCount = 0;
- List<Split> splits =
getBasePaimonTable().newReadBuilder().newScan().plan().splits();
+ Table effectiveTable = getBasePaimonTable();
+ // Statistics and row-count cache planning run before ScanNode and
must not reach an
+ // unsafe manifest executor, even when the foreground relation later
supplies an override.
+ PaimonReaderOptions.validateEffectiveTable(effectiveTable);
Review Comment:
[P1] Build a CPU-capped execution copy before validating this handle.
Catalog validation now deliberately accepts `scan.manifest.parallelism` up to
256, while `validateEffectiveTable` rejects anything above this FE's
`availableProcessors()`; only `runtimeSafeCopyOptions` reconciles those
contracts. `fetchRowCount` feeds `getBasePaimonTable()` directly into the
latter, so a persisted value such as 8 can be accepted cluster-wide yet make
ANALYZE/row-count planning fail on a 4-core FE instead of using 4. The same
raw-handle mismatch remains in no-OPTIONS system tables and
tag/time-travel/branch paths, while the metadata TVF can plan it uncapped.
Ordinary latest scans work only because their projection calls the copy helper.
Please normalize every manifest-planning handle, including hidden/wrapped data
tables, and cover an accepted value above local capacity. This is distinct from
the replay thread: persistence is now stable, but these consumers never apply
the runtime cap.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -958,8 +961,61 @@ public Optional<MvccSnapshot> getSnapshot(TableIf tableIf)
{
if (!(tableIf instanceof MvccTable)) {
return Optional.empty();
}
- MvccTableInfo mvccTableInfo = new MvccTableInfo(tableIf);
- return Optional.ofNullable(snapshots.get(mvccTableInfo));
+ MvccTableInfo defaultKey = new MvccTableInfo(tableIf);
+ MvccSnapshot defaultSnapshot = snapshots.get(defaultKey);
+ if (defaultSnapshot != null) {
+ return Optional.of(defaultSnapshot);
+ }
+ MvccSnapshot only = null;
+ for (Map.Entry<MvccTableInfo, MvccSnapshot> entry :
snapshots.entrySet()) {
+ if (defaultKey.isSameTable(entry.getKey())) {
+ if (only != null) {
+ return Optional.empty();
Review Comment:
[P1] Keep table-only consumers off the raw handle when multiple `OPTIONS`
snapshots exist. Current head intentionally lets an invalid physical
`scan.manifest.parallelism=0` survive in the neutral cache so a relation
override can replace it. Two aliases with distinct safe `OPTIONS` each bind a
valid projected snapshot under different `MvccTableInfo` keys; this branch then
returns empty. `DescriptorTable.toThrift` deduplicates the table and
`PaimonExternalTable.toThrift -> getFullSchema` uses this table-only lookup, so
it falls back to the latest neutral projection and rejects the physical 0 after
both aliases already validated. `OPTIONS` scans avoid table-only partition
pruning, but descriptor serialization is still unconditional. Please make
descriptor/schema consumers relation-aware or provide an ambiguity fallback
that cannot reopen unsafe neutral planning, and add the composed two-alias
descriptor test. This is distinct from the neutral-cache and alias-key threads:
each of thos
e fixes is required for this late failure to become reachable.
--
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]
