wjackson commented on issue #57318:
URL: https://github.com/apache/doris/issues/57318#issuecomment-3679070677
I ran into this problem after upgrading from `3.1.1` to `4.0.2`.
If you don't have the problem, you can reproduce it by adding this before
`cursor.execute(sql)` in the example code:
cursor.execute("SET experimental_enable_nereids_distribute_planner =
false")
If you do have the problem, you can make it go away by adding this before
`cursor.execute(sql)` in the example code:
cursor.execute("SET experimental_enable_nereids_distribute_planner =
true")
Or by setting the variable globally at the `mysql` prompt:
SET GLOBAL experimental_enable_nereids_distribute_planner = true;
The cause: it seems using Flight SQL without the nereids planner is no
longer viable as of 4.0.0:
https://github.com/apache/doris/blob/b4e78bafa82605d013793399a2fc398ee4e10c18/fe/fe-core/src/main/java/org/apache/doris/qe/Coordinator.java#L749
If I'm reading the code correctly, when using Flight SQL
`context.isReturnResultFromLocal()` is `false` and `receivers` stays empty.
`receivers` can't be empty when passed to `new
ResultReceiverConsumer(receivers, timeoutDeadline);`
This problem variable came to light after looking at `fe.audit.log`. In a
fresh Doris 4.0.2 install, when running a simple query via Flight SQL,
`ChangedVariables` was empty. In the upgrade, non-working cluster
`ChangedVariables`` looked like this:
```
ChangedVariables={
"enable_new_type_coercion_behavior":"false"
"enable_audit_plugin":"false"
"insert_visible_timeout_ms":"10000"
"enable_unicode_name_support":"false"
"fetch_splits_max_wait_time_ms":"4000"
"runtime_filter_max_in_num":"1024"
"enable_parallel_result_sink":"false"
"enable_ansi_query_organization_behavior":"false"
"experimental_parallel_scan_max_scanners_count":"48"
"audit_plugin_max_sql_length":"4096"
"exec_mem_limit":"2147483648"
"experimental_enable_nereids_distribute_planner":"false"
"enable_jdbc_cast_predicate_push_down":"false"
"runtime_bloom_filter_max_size":"16777216"
"time_zone":"UTC"}
```
That seems to be all the variables with non-default values post upgrade.
`experimental_enable_nereids_distribute_planner` stuck out since it seemed
relevant to the code around the exception.
I don't think I ever set that variable explicitly so I'm assuming the
default was `false` at the time of my initial install and then carried over
through every upgrade.
Maybe a review of all variables with non-default values makes sense as a
before and after step in docs that cover the upgrade procedure?
The ideal Doris behavior from my perspetive would be to apply all the new
default values except in cases where I've explicitly set the variable.
--
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]
