zclllyybb commented on issue #65871:
URL: https://github.com/apache/doris/issues/65871#issuecomment-5042493856
Breakwater-GitHub-Analysis-Slot: slot_a0fc0f9fb424
This content is generated by AI for reference only.
Initial code-path check on the reported 4.1.3 line:
I checked the FE `SHOW TABLETS FROM ...` implementation in the 4.1.3 release
tag path. The parser accepts `sortClause` for this statement,
`LogicalPlanBuilder.visitShowTabletsFromTable()` passes the parsed `OrderKey`
list into `ShowTabletsFromTableCommand`, and
`ShowTabletsFromTableCommand.validate()` resolves `LocalDataSize` against
`TabletsProcDir.TITLE_NAMES`. `TabletsProcDir.fetchComparableResult()` puts
`LocalDataSize` into the comparable row as `replica.getDataSize()`, so for the
exact query shown in the issue, without `LIMIT`, the FE code is expected to
sort numerically by `LocalDataSize DESC` before converting rows to strings.
The suspicious code-backed bug I can identify is the `ORDER BY` +
`LIMIT/OFFSET` path. `ShowTabletsFromTableCommand.doRun()` computes `sizeLimit`
from `limit/offset` and stops collecting tablet rows once that count is
reached, before `Collections.sort(...)` is called. That means `SHOW TABLETS ...
ORDER BY LocalDataSize DESC LIMIT N` can sort only the first collected rows
instead of all candidate rows, so a zero-size row can appear before a larger
row if the larger row is collected later. If the real command included `LIMIT`,
or if only the first displayed row was inspected, this is likely a real FE bug:
collect all matching tablet rows first, sort by `orderByPairs`, and apply
offset/limit only after sorting.
For the no-limit query exactly as pasted, I do not yet see a code path in
4.1.3 that would simply ignore `ORDER BY LocalDataSize DESC`. The issue
evidence also has a couple of gaps: only one result row is shown, the pasted
4.1.3 header omits `WindowAccessCount` and `LastAccessTime` even though they
are present in the 4.1.3 `SHOW TABLETS` metadata, and the expected row's
`TabletId` does not match the tablet id embedded in its
`MetaUrl`/`CompactionStatus` URLs. So the current issue body is not enough to
prove the no-limit case.
Suggested next steps:
1. Please attach the full raw output for the same session, with:
- `show tablets from dbname.tablename order by LocalDataSize desc;`
- `show tablets from dbname.tablename order by LocalDataSize desc limit
10;`
- `show tablets from dbname.tablename order by TabletId asc limit 10;`
2. Please confirm the exact running build/commit and whether the query is
executed on master or follower FE. For a follower FE, also try `set
forward_to_master = true;` and rerun the same `SHOW TABLETS` command in the
same connection.
3. If the `LIMIT` variant reproduces, the likely fix is in
`ShowTabletsFromTableCommand.doRun()`: do not stop collection by `sizeLimit`
before sorting; apply limit/offset after global sort, and add a regression/FE
test covering `ORDER BY LocalDataSize DESC LIMIT 1`.
4. If the no-limit variant is still globally unordered after the above, the
next useful evidence is the complete output plus FE version/build info, because
the current 4.1.3 code path should not drop the parsed order key for
`LocalDataSize`.
--
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]
