Doris-Breakwater commented on issue #66203:
URL: https://github.com/apache/doris/issues/66203#issuecomment-5112065303

   Breakwater-GitHub-Analysis-Slot: slot_3754bebfa3ac
   
   This content is generated by AI for reference only.
   
   Initial assessment: this is a confirmed BE bug in 4.1.1, but it has already 
been fixed and backported. It is not specific to storage format V3.
   
   The error text uniquely matches `RuntimePredicate::RuntimePredicate()`. For 
an `ORDER BY ... LIMIT` plan, the FE can push a TopN runtime predicate to the 
scan. In the [4.1.1 
implementation](https://github.com/apache/doris/blob/4.1.1/be/src/runtime/runtime_predicate.cpp#L79-L82),
 `RuntimePredicate::_init()` accepts the other sortable type families but omits 
`TIMESTAMPTZ`, so constructing that predicate throws the reported `meet invalid 
type, type=TIMESTAMPTZ` exception. This happens before the storage-layer 
comparison predicate is created; `"storage_format" = "V3"` and 
`"store_row_column" = "true"` are therefore not the root cause.
   
   The merged fix [#63220](https://github.com/apache/doris/pull/63220) adds 
`is_timestamptz_type(type)` to that allow-list and adds TopN regression 
coverage for ascending/descending order, limit/offset, mixed time zones, and 
nullable values. It was backported to branch 4.1 by 
[#63237](https://github.com/apache/doris/pull/63237). Source/tag inspection 
confirms that the change is absent from tag `4.1.1` and present in tags `4.1.2` 
and `4.1.3`.
   
   Suggested maintainer action:
   
   - Treat this as already fixed (or duplicate of the merged fix) rather than 
requesting a new PR.
   - Ask the reporter to upgrade to Doris 4.1.2 or later, preferably 4.1.3, and 
retry.
   - If an immediate upgrade is impossible, `SET topn_filter_ratio = 0;` can be 
tried as a temporary session-level workaround to prevent generation of this 
TopN filter when table statistics are available. Confirm with `EXPLAIN` that 
the scan no longer contains `TOPN OPT`; upgrading remains the reliable fix.
   
   The pasted SQL is not directly runnable: the DDL defines `created_at`, while 
the query orders by `updated_at`, and `FROM inland_ test_db.test_tz_v3` appears 
malformed. These inconsistencies do not change the root-cause match because the 
serialized failing expression is already a resolved `TIMESTAMPTZ` slot, but a 
corrected standalone reproducer would make the report clearer.
   
   No additional logs are needed for the initial classification. If the same 
error remains after upgrading, please request:
   
   - `SELECT VERSION()` and the version reported for every BE (to rule out a 
mixed-version cluster);
   - the corrected DDL/query and `EXPLAIN VERBOSE` output;
   - the query ID and the matching BE log lines containing the exception.
   
   This conclusion is based on source and release-tag inspection; I did not run 
a local cluster reproduction.
   


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