[fix](arrow-flight) Release a finished Flight query's coordinator instead of holding it until wait_timeout by raghav-reglobe · Pull Request #67504 · apache/doris

raghav-reglobe · 2026-09-03T15:21:19Z

What problem does this PR solve?

Issue Number: close#67503

Related PR: #64799 (kept the coordinator alive across GetFlightInfo → DoGet so the BE can fetch external-table splits; this PR narrows that to the queries that actually need it and bounds how long an abandoned session can hold the rest)

Problem Summary:

Since #64799 every Arrow Flight SQL query whose results are produced on the BE kept its coordinator alive after GetFlightInfo, until the session ran its next query or was closed. The coordinator holds the query's workload-group queue slot and its active_queries registration. Most Flight clients open a session per query and never send CloseSession (the ADBC/JDBC drivers don't do it on connection close, as the comment in DorisFlightSqlProducer.closeSession notes), so each abandoned session pinned one slot for up to wait_timeout (8h by default).

Observed on a 2-FE cluster with a max_concurrency=8 workload group: eight finished Flight queries sat in information_schema.active_queries as RUNNING for over an hour, and every later query in the group failed with query queue timeout, timeout: 60000 ms. Full write-up in #67503.

This PR fixes it in two steps:

Only defer the coordinator when the BE still needs it. The deferral added by [fix](arrow-flight) Keep coordinator alive across GetFlightInfo/DoGet for external table scan #64799 is required only for an external-table scan in batch mode, where the BE lazily fetches splits during DoGet from the split source the coordinator holds. Every other query (internal tables, external tables in non-batch mode) now closes its coordinator at the end of GetFlightInfo again, releasing the queue slot and the active_queries entry right away. That is safe: the BE buffers its results independently of the coordinator, and finalizing the FE side does not cancel BE execution (QeProcessorImpl.reportExecStatus accepts reports for an unregistered query, and Coordinator.close() only releases the queue token and the split sources). New predicates ScanNode.hasBatchSplitSource() / Coordinator.hasBatchSplitSource() drive the gate in StmtExecutor.executeAndSendResult.
Bound the remaining deferred queries without killing the session. New mutable FE config arrow_flight_deferred_query_idle_timeout_second (default 3600). Once a Flight session has been sleeping for longer than this since its last query started, the connection timeout checker finalizes the session's deferred executors (releasing the slot and the registration) and leaves the session alive; wait_timeout still governs the session itself. The bound is floored at the execution timeout the deferred query actually ran with, captured when the executor is deferred (SET_VAR hint values are reverted at the end of execute(), so the session value cannot be read later). 0 disables the bound.

Why not kill the session (the first revision of this PR): a killed Flight session's bearer token stays in the token cache marked as already used, so the client's next call on it fails with UserSession expire after access and has to re-handshake. With a 1h bound, every pooled or BI-tool Flight connection that idles for an hour would fail once on its next use. Reaping only the deferred query releases the leaked resources with no client-visible change.

Release note

Arrow Flight SQL: a query no longer holds its workload-group queue slot and active_queries entry after GetFlightInfo unless it is an external-table scan in batch mode, the only case where the BE still fetches splits from the FE during DoGet. For that case a new FE config arrow_flight_deferred_query_idle_timeout_second (default 1h) releases the coordinator of an idle, never-closed session without killing the session.

Check List (For Author)

Test
- Regression test (arrow_flight_sql_p0/test_arrow_flight_query_release: a finished Flight query on an internal table no longer occupies a max_concurrency=1 group and is gone from active_queries; external_table_p0/iceberg/test_iceberg_arrow_flight_split_source: the batch-mode scan stays registered after DoGet and is released by the idle reaper while the session survives)
- Unit Test (FlightSqlDeferredQueryIdleTimeoutTest: the reaper through checkTimeout, the exec-timeout floor, 0 disables, nothing deferred, MySQL untouched; ArrowFlightDeferralGateTest: the batch-split-source predicates; StmtExecutorTest.testDeferForArrowFlightFreezesExecTimeoutInEffect)
- Manual test (the first revision was verified on a test cluster with an 8s bound, see the PR history; the current revision is covered by the regression tests above)
- No need to test or manual test. Explain why:
  - This is a refactor/code format and no logic has been changed.
  - Previous test can cover this change.
  - No code files have been changed.
  - Other reason
Behavior changed:
- No.
- Yes. (1) A Flight query that is not an external-table batch-mode scan releases its coordinator, queue slot and active_queries entry at the end of GetFlightInfo, as it did before [fix](arrow-flight) Keep coordinator alive across GetFlightInfo/DoGet for external table scan #64799. (2) The deferred coordinator of a batch-mode scan on an idle session is released after 1h by default instead of at wait_timeout; set arrow_flight_deferred_query_idle_timeout_second=0 for the previous behavior. Sessions are never killed by this change.
Does this need documentation?
- No.
- Yes. New FE config arrow_flight_deferred_query_idle_timeout_second — doris-website PR to follow once this is reviewed.

Check List (For Reviewer who merge this PR)

Confirm the release note
Confirm test cases
Confirm document
Add branch pick label

hello-stephen · 2026-09-03T15:21:26Z

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

…instead of killing the session Follow-up to the first revision of apache#67504 after review: - Narrow the apache#64799 deferral gate: only a coordinator that still hands out splits to the BE (an external-table scan in batch mode, see the new ScanNode/Coordinator.hasBatchSplitSource) outlives GetFlightInfo. Every other Arrow Flight query closes its coordinator at the end of GetFlightInfo again, releasing the workload-group queue slot and the active_queries entry right away. Finalizing the FE side does not cancel BE execution, so DoGet is unaffected. - Replace arrow_flight_session_idle_timeout_second by arrow_flight_deferred_query_idle_timeout_second: the connection timeout checker now finalizes the deferred executors of a sleeping Flight session and leaves the session alive; wait_timeout still governs the session. A killed session would have made the client's next call fail with "UserSession expire after access". - Freeze the execution timeout when the executor is deferred, so a SET_VAR query_timeout hint (reverted at the end of execute()) still floors the bound. - Tests: FlightSqlDeferredQueryIdleTimeoutTest drives checkTimeout, ArrowFlightDeferralGateTest covers the predicates, StmtExecutorTest covers the frozen timeout; regression cases for the internal-table release (arrow_flight_sql_p0) and the idle reaper on a batch-mode Iceberg scan. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApxvNkMK8TiNycv44P8Ezk

morningman · 2026-09-05T07:33:09Z

Thanks for the precise write-up, the problem is real and #67503 nails the mechanism. I reviewed the branch and pushed a revision on top of your commit (the PR allows maintainer edits); the description is updated to match. What changed and why:

Reap the deferred query instead of killing the session. What leaks is the deferred coordinator, not the session. Killing the session has a client-visible cost: unregisterConnection leaves the bearer token in the cache marked as already used, so the client's next call fails with UserSession expire after access and has to re-handshake. With a 1h default, every pooled / BI-tool Flight connection that idles for an hour would fail once on its next use. The checker now finalizes the session's deferred executors when the bound passes and leaves the session under wait_timeout. The config is renamed to arrow_flight_deferred_query_idle_timeout_second accordingly.
Narrow the deferral gate to the queries that need it.[fix](arrow-flight) Keep coordinator alive across GetFlightInfo/DoGet for external table scan #64799 deferred every BE-served Flight query, but only an external-table scan in batch mode needs the coordinator after GetFlightInfo (the BE fetches splits from its split source during DoGet). Finalizing the FE side does not cancel BE execution (reportExecStatus accepts reports for an unregistered query; Coordinator.close() only releases the queue token and the split sources), so every other query now closes its coordinator at the end of GetFlightInfo again, exactly as before [fix](arrow-flight) Keep coordinator alive across GetFlightInfo/DoGet for external table scan #64799. This removes the leak for internal tables entirely, with no timeout involved; the idle bound only has to cover batch-mode external scans. New predicates: ScanNode.hasBatchSplitSource() / Coordinator.hasBatchSplitSource().
Capture the exec timeout when the executor is deferred. While the session sleeps executor is null, so getExecTimeoutS() returned the current session query_timeout; SET_VAR hint values are reverted at the end of execute(). A query run with /*+ SET_VAR(query_timeout=7200) */ would have been cut at 3600s, the case the floor is meant to protect. StmtExecutor.deferForArrowFlight() now freezes the value and the bound uses the max over the deferred executors.
Tests.FlightSqlSessionIdleTimeoutTest (formula only) is replaced by FlightSqlDeferredQueryIdleTimeoutTest, which drives checkTimeout and asserts both the release and that the session is not killed; ArrowFlightDeferralGateTest covers the predicates; StmtExecutorTest covers the frozen timeout. Two regression cases: arrow_flight_sql_p0/test_arrow_flight_query_release (internal table no longer occupies a max_concurrency=1 group) and an extension of test_iceberg_arrow_flight_split_source (batch-mode scan stays registered, then is released by the reaper while the session keeps working).
Smaller things from the review: the Config description now states the floor and that the session is not killed; masterOnly = false dropped; FeConstants.runningUnitTest is restored after the test.

Pick labels: #64799 is in 4.0.8 / 4.1.4, so this needs dev/4.0.x and dev/4.1.x.

morningman · 2026-09-05T07:33:12Z

run buildall

…rom wait_timeout A Flight SQL session idles under the same wait_timeout as a MySQL connection (28800s by default). Since the coordinator of a BE-served Flight query is kept alive across GetFlightInfo -> DoGet until the session's next query or its close, an abandoned session - a client that opens a session per query and never sends CloseSession - keeps that query's workload-group queue slot for the whole wait_timeout. Eight such sessions fill a max_concurrency=8 group and every later query in it fails with "query queue timeout". Add a mutable FE config, arrow_flight_session_idle_timeout_second (default 3600), applied by the existing connection timeout checker to ARROW_FLIGHT_SQL contexts only as min(wait_timeout, max(config, exec timeout)). The exec-timeout floor matters: a Flight session is COM_SLEEP while the client drains the result via DoGet and its idle clock runs from the query's start, so a bound below query_timeout would kill a long result stream before the query's own timeout could. 0 disables the bound. MySQL-protocol connections are unchanged. The kill log line now reports the effective idle timeout. Signed-off-by: Raghvendra Singh <raghav@cashify.in> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…instead of killing the session Follow-up to the first revision of apache#67504 after review: - Narrow the apache#64799 deferral gate: only a coordinator that still hands out splits to the BE (an external-table scan in batch mode, see the new ScanNode/Coordinator.hasBatchSplitSource) outlives GetFlightInfo. Every other Arrow Flight query closes its coordinator at the end of GetFlightInfo again, releasing the workload-group queue slot and the active_queries entry right away. Finalizing the FE side does not cancel BE execution, so DoGet is unaffected. - Replace arrow_flight_session_idle_timeout_second by arrow_flight_deferred_query_idle_timeout_second: the connection timeout checker now finalizes the deferred executors of a sleeping Flight session and leaves the session alive; wait_timeout still governs the session. A killed session would have made the client's next call fail with "UserSession expire after access". - Freeze the execution timeout when the executor is deferred, so a SET_VAR query_timeout hint (reverted at the end of execute()) still floors the bound. - Tests: FlightSqlDeferredQueryIdleTimeoutTest drives checkTimeout, ArrowFlightDeferralGateTest covers the predicates, StmtExecutorTest covers the frozen timeout; regression cases for the internal-table release (arrow_flight_sql_p0) and the idle reaper on a batch-mode Iceberg scan. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApxvNkMK8TiNycv44P8Ezk

morningman · 2026-09-05T07:44:22Z

Rebased onto current master (b58b2c53ff5) and force-pushed. The only conflict was the comment above the deferral gate in StmtExecutor.executeAndSendResult against #67487: kept the narrowed gate and adopted #67487's wording about short-circuit point queries no longer reaching it. Master also moved StmtExecutorTest to JUnit 5 assertions, so the new test in that file follows suit. No other changes; the affected FE unit tests and checkstyle pass locally on the rebased tree.

morningman · 2026-09-05T07:44:26Z

run buildall

hello-stephen · 2026-09-05T09:11:05Z

TPC-H: Total hot run time: 16940 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit c662d85d1634bf1af5f37ca8cc265c1d42ab0777, data reload: false
------ Round 1 ----------------------------------
============================================
q1	17593	3012	3010	3010
q2	2086	281	235	235
q3	10223	888	525	525
q4	4695	252	200	200
q5	7672	562	379	379
q6	141	116	98	98
q7	539	498	398	398
q8	9234	900	843	843
q9	3517	2445	2420	2420
q10	6521	873	712	712
q11	394	208	190	190
q12	611	258	201	201
q13	18109	1535	1177	1177
q14	162	147	144	144
q15	q16	440	405	367	367
q17	1430	896	796	796
q18	3058	2271	2257	2257
q19	1135	904	736	736
q20	372	280	205	205
q21	5298	1809	1950	1809
q22	325	266	238	238
Total cold run time: 93555 ms
Total hot run time: 16940 ms
----- Round 2, with runtime_filter_mode=off -----
============================================
q1	3386	3328	3300	3300
q2	510	390	373	373
q3	2195	2388	2189	2189
q4	1191	1187	911	911
q5	2184	2152	2160	2152
q6	164	123	89	89
q7	1064	950	891	891
q8	1616	1406	1410	1406
q9	3156	3125	3112	3112
q10	1866	1836	1629	1629
q11	356	276	260	260
q12	464	430	352	352
q13	1502	1550	1160	1160
q14	185	184	161	161
q15	q16	403	404	355	355
q17	3608	3353	3308	3308
q18	4853	4492	4756	4492
q19	935	961	867	867
q20	1029	967	851	851
q21	3898	3245	3182	3182
q22	406	333	323	323
Total cold run time: 34971 ms
Total hot run time: 31363 ms

hello-stephen · 2026-09-05T09:17:37Z

TPC-DS: Total hot run time: 83156 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit c662d85d1634bf1af5f37ca8cc265c1d42ab0777, data reload: false
query5	4264	432	357	357
query6	395	143	129	129
query7	4889	414	248	248
query8	293	129	120	120
query9	8698	3003	2999	2999
query10	398	228	191	191
query11	5393	1059	923	923
query12	127	73	72	72
query13	1203	455	326	326
query14	6093	2259	2149	2149
query14_1	2004	2027	2039	2027
query15	173	124	121	121
query16	922	406	385	385
query17	818	480	393	393
query18	2340	334	246	246
query19	164	156	114	114
query20	74	69	78	69
query21	202	106	93	93
query22	5405	5316	5393	5316
query23	6812	6311	6207	6207
query23_1	6166	6021	6272	6021
query24	7307	1103	793	793
query24_1	819	805	816	805
query25	438	315	263	263
query26	1226	237	140	140
query27	2784	416	261	261
query28	4667	1533	1514	1514
query29	956	455	376	376
query30	255	159	133	133
query31	824	408	331	331
query32	129	79	77	77
query33	463	230	187	187
query34	1000	840	487	487
query35	398	401	362	362
query36	584	586	542	542
query37	123	84	73	73
query38	1003	876	815	815
query39	502	516	492	492
query39_1	470	454	509	454
query40	205	94	80	80
query41	60	58	59	58
query42	76	80	74	74
query43	242	241	211	211
query44	1031	567	598	567
query45	114	107	100	100
query46	755	874	513	513
query47	769	757	720	720
query48	312	309	237	237
query49	537	237	206	206
query50	738	258	196	196
query51	8149	7981	8032	7981
query52	69	69	58	58
query53	195	214	209	209
query54	231	185	162	162
query55	72	60	65	60
query56	202	170	177	170
query57	719	662	640	640
query58	207	162	179	162
query59	1202	1231	1100	1100
query60	257	193	217	193
query61	134	123	139	123
query62	366	209	198	198
query63	167	135	156	135
query64	2759	675	651	651
query65	1607	1569	1604	1569
query66	1775	258	208	208
query67	9843	9720	9786	9720
query68	2744	1238	696	696
query69	334	227	213	213
query70	665	630	633	630
query71	257	184	164	164
query72	2474	1870	1585	1585
query73	643	601	351	351
query74	1553	1230	1160	1160
query75	1186	1116	980	980
query76	2284	735	565	565
query77	263	278	214	214
query78	3998	3692	3224	3224
query79	2993	859	563	563
query80	1602	346	297	297
query81	509	159	137	137
query82	626	128	98	98
query83	282	214	192	192
query84	306	114	92	92
query85	820	367	312	312
query86	401	184	179	179
query87	1015	994	902	902
query88	2905	2136	2103	2103
query89	298	204	180	180
query90	1972	149	136	136
query91	133	123	106	106
query92	81	73	72	72
query93	1674	1083	678	678
query94	628	269	238	238
query95	517	332	245	245
query96	781	578	263	263
query97	1052	1041	1002	1002
query98	157	134	141	134
query99	418	347	314	314
Total cold run time: 178604 ms
Total hot run time: 83156 ms

hello-stephen · 2026-09-05T09:22:00Z

ClickBench: Total hot run time: 14.81 s

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit c662d85d1634bf1af5f37ca8cc265c1d42ab0777, data reload: false
query1	0.01	0.01	0.00
query2	0.08	0.03	0.03
query3	0.26	0.10	0.10
query4	1.61	0.11	0.10
query5	0.18	0.16	0.18
query6	1.24	0.72	0.68
query7	0.03	0.00	0.01
query8	0.05	0.03	0.04
query9	0.28	0.21	0.22
query10	0.36	0.35	0.36
query11	0.18	0.12	0.11
query12	0.15	0.12	0.12
query13	0.31	0.32	0.32
query14	0.46	0.45	0.46
query15	0.37	0.35	0.36
query16	0.22	0.22	0.22
query17	0.72	0.70	0.68
query18	0.16	0.17	0.17
query19	1.20	1.18	1.16
query20	0.01	0.01	0.01
query21	15.43	0.18	0.11
query22	5.07	0.04	0.04
query23	16.17	0.26	0.11
query24	2.97	0.32	0.25
query25	0.09	0.04	0.03
query26	0.83	0.18	0.12
query27	0.03	0.04	0.03
query28	3.63	0.59	0.27
query29	12.42	3.17	2.59
query30	0.26	0.11	0.12
query31	2.76	0.38	0.17
query32	3.51	0.32	0.24
query33	1.66	1.66	1.44
query34	15.47	2.23	1.82
query35	1.79	1.74	1.74
query36	0.47	0.30	0.28
query37	0.06	0.03	0.04
query38	0.05	0.03	0.03
query39	0.03	0.02	0.02
query40	0.11	0.08	0.07
query41	0.09	0.02	0.02
query42	0.03	0.03	0.02
query43	0.04	0.03	0.02
Total cold run time: 90.85 s
Total hot run time: 14.81 s

hello-stephen · 2026-09-05T09:30:15Z

FE UT Coverage Report

Increment line coverage 88.89% (32/36) 🎉
Increment coverage report
Complete coverage report

…elease path Follow-up to apache#67504 after review: the deferral gate this PR narrows moves exactly one case - an external-table scan that is NOT in batch mode - from "coordinator deferred past GetFlightInfo" to "coordinator closed at the end of GetFlightInfo". That case had no Arrow Flight coverage anywhere: the only external-catalog Flight suite forces batch mode on its session and asserts it, so all four of its data queries exercise the deferred side, and the new arrow_flight_sql_p0 case covers the eager side only for an internal table, where neither a split source nor a connector read session exists. Add the missing cell to test_iceberg_arrow_flight_split_source, reusing the catalog and Flight connection it already sets up: - A negative control mirroring the existing batch assertion: "(approximate)" is emitted only when isBatchMode(), so its absence proves the scan really is on the synchronous split path. Without it the block could silently run in batch mode and pass. enable_external_table_batch_mode=false is a reliable off switch here - IcebergScanPlanProvider.streamingSplitEstimate returns -1 when it is unset, and Iceberg does not override supportsBatchScan (SPI default false), so the partition-count flavor cannot route around it. - A full scan that must return every row: the FE has closed the coordinator by then, and the BE buffers the result independently of it. - A check that the release really was eager - the query is gone from active_queries right after the client has the rows. No polling is needed because finalizeQuery() runs inside GetFlightInfo. A distinct limit keeps the query text apart from the other scans and the LIKE pattern is built with CONCAT so the probe cannot match itself. Batch mode is restored afterwards, since the idle-reaper assertions below need a deferred coordinator to release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGqBt7EdtV7rc7tD4nmEqx

morningman · 2026-09-05T16:13:55Z

run buildall

hello-stephen · 2026-09-05T16:15:26Z

FE Regression Coverage Report

Increment line coverage 86.11% (31/36) 🎉
Increment coverage report
Complete coverage report

hello-stephen · 2026-09-05T17:36:39Z

TPC-H: Total hot run time: 16970 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit 888313142ef112a5dd52d4e536259832b16e3852, data reload: false
------ Round 1 ----------------------------------
============================================
q1	17597	3150	3112	3112
q2	2190	250	226	226
q3	10177	890	524	524
q4	4673	249	203	203
q5	7673	558	395	395
q6	133	112	93	93
q7	538	486	386	386
q8	9244	890	876	876
q9	3442	2393	2380	2380
q10	6497	834	728	728
q11	401	211	179	179
q12	611	271	205	205
q13	18112	1526	1171	1171
q14	159	145	142	142
q15	q16	444	397	370	370
q17	1404	938	811	811
q18	3130	2242	2255	2242
q19	1275	828	714	714
q20	398	284	206	206
q21	5568	1771	1794	1771
q22	331	264	236	236
Total cold run time: 93997 ms
Total hot run time: 16970 ms
----- Round 2, with runtime_filter_mode=off -----
============================================
q1	3501	3449	3464	3449
q2	516	398	371	371
q3	2313	2641	2196	2196
q4	1200	1172	906	906
q5	2199	2126	2112	2112
q6	163	123	85	85
q7	1046	976	924	924
q8	1633	1451	1460	1451
q9	3199	3172	3145	3145
q10	1856	1795	1625	1625
q11	368	279	258	258
q12	457	436	357	357
q13	1469	1540	1160	1160
q14	169	170	153	153
q15	q16	390	395	385	385
q17	3616	3319	3265	3265
q18	4881	4453	4859	4453
q19	949	859	846	846
q20	976	950	820	820
q21	3894	3151	3246	3151
q22	402	347	305	305
Total cold run time: 35197 ms
Total hot run time: 31417 ms

hello-stephen · 2026-09-05T17:43:10Z

TPC-DS: Total hot run time: 82259 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit 888313142ef112a5dd52d4e536259832b16e3852, data reload: false
query5	4282	420	345	345
query6	397	145	123	123
query7	4929	419	236	236
query8	298	125	132	125
query9	8694	2982	2980	2980
query10	381	223	183	183
query11	5372	1059	927	927
query12	118	73	72	72
query13	1189	448	298	298
query14	6157	2230	2104	2104
query14_1	2018	2006	1995	1995
query15	170	124	114	114
query16	922	369	315	315
query17	817	462	374	374
query18	2344	329	230	230
query19	165	133	106	106
query20	78	70	77	70
query21	192	100	85	85
query22	5548	5213	5244	5213
query23	6760	6332	6012	6012
query23_1	6184	6097	5931	5931
query24	7264	1103	761	761
query24_1	770	792	751	751
query25	414	269	245	245
query26	1228	251	128	128
query27	2768	405	247	247
query28	4738	1483	1491	1483
query29	915	422	332	332
query30	267	153	133	133
query31	816	399	324	324
query32	127	69	71	69
query33	469	217	179	179
query34	1013	871	496	496
query35	422	395	349	349
query36	578	563	520	520
query37	120	78	69	69
query38	1022	836	830	830
query39	508	478	489	478
query39_1	500	462	480	462
query40	207	97	80	80
query41	60	57	57	57
query42	74	73	77	73
query43	243	249	215	215
query44	1016	560	566	560
query45	112	108	101	101
query46	793	837	540	540
query47	778	790	709	709
query48	319	322	244	244
query49	554	256	194	194
query50	777	265	206	206
query51	8344	8520	8231	8231
query52	67	68	60	60
query53	198	200	159	159
query54	323	189	171	171
query55	69	62	57	57
query56	226	180	171	171
query57	701	639	634	634
query58	215	177	182	177
query59	1235	1317	1117	1117
query60	239	188	169	169
query61	136	119	136	119
query62	378	210	179	179
query63	171	143	134	134
query64	2837	702	611	611
query65	1609	1558	1585	1558
query66	2017	267	220	220
query67	10092	9826	9616	9616
query68	2783	1183	769	769
query69	344	231	196	196
query70	691	611	648	611
query71	248	172	193	172
query72	2331	1748	1626	1626
query73	653	562	337	337
query74	1564	1229	1135	1135
query75	1177	1095	962	962
query76	2291	743	551	551
query77	252	283	221	221
query78	3858	3599	3132	3132
query79	2578	827	595	595
query80	1568	319	257	257
query81	487	158	135	135
query82	639	127	98	98
query83	291	205	191	191
query84	297	115	90	90
query85	774	362	303	303
query86	392	173	176	173
query87	1037	974	928	928
query88	2796	2106	2102	2102
query89	293	199	173	173
query90	1985	132	130	130
query91	132	120	102	102
query92	82	71	67	67
query93	1478	1040	719	719
query94	641	271	226	226
query95	499	317	223	223
query96	821	565	268	268
query97	1076	1052	1033	1033
query98	166	139	136	136
query99	419	347	309	309
Total cold run time: 178798 ms
Total hot run time: 82259 ms

hello-stephen · 2026-09-05T17:47:32Z

ClickBench: Total hot run time: 14.75 s

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit 888313142ef112a5dd52d4e536259832b16e3852, data reload: false
query1	0.01	0.00	0.00
query2	0.08	0.04	0.04
query3	0.25	0.10	0.11
query4	1.61	0.10	0.09
query5	0.18	0.16	0.16
query6	1.24	0.68	0.68
query7	0.03	0.00	0.01
query8	0.05	0.03	0.03
query9	0.30	0.22	0.22
query10	0.34	0.34	0.34
query11	0.18	0.12	0.12
query12	0.15	0.13	0.12
query13	0.32	0.31	0.31
query14	0.45	0.45	0.45
query15	0.38	0.38	0.35
query16	0.23	0.23	0.23
query17	0.74	0.72	0.69
query18	0.18	0.16	0.17
query19	1.24	1.13	1.16
query20	0.01	0.01	0.01
query21	15.47	0.17	0.12
query22	5.07	0.04	0.04
query23	16.14	0.24	0.11
query24	3.05	0.33	0.28
query25	0.11	0.05	0.04
query26	0.73	0.17	0.12
query27	0.04	0.04	0.02
query28	3.63	0.55	0.26
query29	12.50	3.26	2.56
query30	0.26	0.12	0.13
query31	2.76	0.39	0.17
query32	3.49	0.30	0.23
query33	1.41	1.39	1.38
query34	15.40	2.23	1.81
query35	1.78	1.74	1.76
query36	0.47	0.29	0.29
query37	0.06	0.04	0.04
query38	0.05	0.03	0.04
query39	0.03	0.03	0.02
query40	0.12	0.08	0.08
query41	0.08	0.02	0.02
query42	0.04	0.02	0.03
query43	0.03	0.02	0.02
Total cold run time: 90.69 s
Total hot run time: 14.75 s

raghav-reglobe requested review from 924060929 and morrySnow as code owners September 3, 2026 15:21

morningman changed the title ~~[fix](arrow-flight) Bound idle Arrow Flight SQL sessions separately from wait_timeout~~[fix](arrow-flight) Release a finished Flight query's coordinator instead of holding it until wait_timeoutSep 5, 2026

Raghavand others added 2 commits September 5, 2026 15:37

morningman added the dev/4.2.x label Sep 5, 2026

morningman force-pushed the fix-arrow-flight-session-idle-timeout branch from 212a026 to c662d85Compare September 5, 2026 07:44

Uh oh!

Conversation

raghav-reglobe commented Sep 3, 2026• edited by morningman Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What problem does this PR solve?

Release note

Check List (For Author)

Check List (For Reviewer who merge this PR)

Uh oh!

hello-stephen commented Sep 3, 2026

Uh oh!

morningman commented Sep 5, 2026

Uh oh!

morningman commented Sep 5, 2026

Uh oh!

morningman commented Sep 5, 2026

Uh oh!

morningman commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

FE UT Coverage Report

Uh oh!

morningman commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

FE Regression Coverage Report

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

hello-stephen commented Sep 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

raghav-reglobe commented Sep 3, 2026•
edited by morningman
Loading