[Bug] doris 4.1 版本 无法使用 TIMESTAMPTZ 类型字段去order 排序

[jimmy-boss]

Search before asking

• I had searched in the issues and found no similar issues.

Version

4.1.1

What's Wrong?

CREATE TABLE IF NOT EXISTS test_db.test_tz_v3 (
uuid                        varchar(256) NOT NULL COMMENT '唯一标识',
created_at              TIMESTAMPTZ(3)  DEFAULT CURRENT_TIMESTAMP COMMENT '记录创建时间'
) ENGINE=OLAP
UNIQUE KEY(uuid)
COMMENT ''
DISTRIBUTED BY HASH(uuid) BUCKETS 2
PROPERTIES (
    "storage_format"             = "V3", -- 使用v3存储格式时,会出现order TIMESTAMPTZ 报错
    "store_row_column"           = "true"
);

SELECT * FROM inland_ test_db.test_tz_v3
ORDER BY updated_at DESC
LIMIT 0, 20;

报错：
meet invalid type, type=TIMESTAMPTZ, expr=TExprNode(node_type=SLOT_REF, type=TTypeDesc(types=[TTypeNode(type=SCALAR, scalar_type=TScalarType(type=TIMESTAMPTZ, len=, precision=18, scale=3, variant_max_subcolumns_count=0, variant_enable_doc_mode=0), struct_fields=, contains_null=, contains_nulls=)], is_nullable=, byte_size=-1, sub_types=, result_is_nullable=, function_name=, be_exec_version=), opcode=, num_children=0, agg_expr=, bool_literal=, case_expr=, date_literal=, float_literal=, int_literal=, in_predicate=, is_null_pred=, like_pred=, literal_pred=, slot_ref=TSlotRef(slot_id=37, tuple_id=0, col_unique_id=37, is_virtual_slot=0), string_literal=, tuple_is_null_pred=, info_func=, decimal_literal=, output_scale=-1, fn_call_expr=, large_int_literal=, output_column=, output_type=, vector_opcode=, fn=, vararg_start_idx=, child_type=, is_nullable=1, json_literal=, schema_change_expr=, column_ref=, match_predicate=, ipv4_literal=, ipv6_literal=, label=updated_at, timev2_literal=, varbinary_literal=, is_cast_nullable=, search_param=, short_circuit_evaluation=

What You Expected?

不报错

How to Reproduce?

请插入大概1000条数据，
再进行查询，会报错
使用 "storage_format" = "V2" 建表时，当设置 SET topn_opt_limit_threshold = 0; 时会不报错
使用 "storage_format" = "V3" 建表时，当设置 SET topn_filter_ratio = 0 ; 时会不报错

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[Doris-Breakwater]

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

[jimmy-boss]

设置set global topn_filter_ratio = 0； 能临时不报错；
升级到最新版本永久解决