From e186fd9646a0dda6767dc5535b6c23fdde039a7b Mon Sep 17 00:00:00 2001 From: morningman Date: Wed, 9 Sep 2026 18:22:22 +0800 Subject: [PATCH] [fix](regression) Deflake test_sql_cache_over_arrow_flight The suite primes four sql cache entries through the MySQL control session, runs the same statements over Arrow Flight, and finally asserts the entries are still there, to prove that a flight query never consumes the cache. That last block fails intermittently: in p0 build 124525 the `select 1 as c, 'x' as s` entry was gone 299ms after it had been primed, and the suite has failed six times on master and branch-4.1 since it was added. The FE sql cache is a single Caffeine map shared by every session, bounded by Config.sql_cache_manage_num, which defaults to 100. Caffeine admits a newcomer through a window sized at 1% of that bound, so at the default the window holds a single entry and a just cached statement is dropped again as soon as any other session caches anything. enable_sql_cache defaults to true, so the rest of the p0 suite running concurrently against the same FE is already enough: only 15 distinct selects ran cluster wide during that 299ms window, far fewer than the 100 an LRU would have needed. The other five sql cache suites in the repo (mv_with_sql_cache, mtmv_with_sql_cache, parse_sql_from_sql_cache, union_all_compensate, union_rewrite_grace_big) all raise the bound for this reason; this one was missing it. Raise it here as well while the suite runs, and put it back afterwards so the rest of the run does not keep 10000 cached plans and their result rows alive in the FE heap. The suites that raise it without restoring it left 97k live SqlCacheContext instances behind in the same build. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Njd8iDxdqc19QbLdNtZ7Pt --- .../test_sql_cache_over_arrow_flight.groovy | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/regression-test/suites/arrow_flight_sql_p0/test_sql_cache_over_arrow_flight.groovy b/regression-test/suites/arrow_flight_sql_p0/test_sql_cache_over_arrow_flight.groovy index 577665b275b47d..a3fb39d38d9a60 100644 --- a/regression-test/suites/arrow_flight_sql_p0/test_sql_cache_over_arrow_flight.groovy +++ b/regression-test/suites/arrow_flight_sql_p0/test_sql_cache_over_arrow_flight.groovy @@ -84,6 +84,19 @@ suite("test_sql_cache_over_arrow_flight") { withGlobalLock("cache_last_version_interval_second") { runOnMysql "ADMIN SET ALL FRONTENDS CONFIG ('cache_last_version_interval_second' = '0')" + // The FE sql cache is a single Caffeine map shared by every session and bounded by + // Config.sql_cache_manage_num, which defaults to 100. Caffeine admits a newcomer through a + // window sized at 1% of that bound, so at the default a just cached statement is dropped + // again as soon as any other session caches anything -- and the whole p0 suite runs + // concurrently against this FE with enable_sql_cache on by default. The entries primed + // below would then be gone before the checks at the end of this suite, which is what made + // it flaky. Raise the bound while this suite runs, like the other sql cache suites do, and + // put it back afterwards so the rest of the run does not keep 10000 cached plans and their + // result rows alive in the FE heap. + def originalSqlCacheNum = + runOnMysql("ADMIN SHOW FRONTEND CONFIG LIKE 'sql_cache_manage_num'")[0][1].toString() + runOnMysql "ADMIN SET ALL FRONTENDS CONFIG ('sql_cache_manage_num' = '10000')" + def dbName = context.dbName runOnMysql "USE `${dbName}`" runOnFlight "USE `${dbName}`" @@ -164,5 +177,7 @@ suite("test_sql_cache_over_arrow_flight") { assertTrue(hasSqlCache(scalarSql)) assertTrue(hasSqlCache(rawStateSql)) assertTrue(hasSqlCache(convertedSql)) + + runOnMysql "ADMIN SET ALL FRONTENDS CONFIG ('sql_cache_manage_num' = '${originalSqlCacheNum}')" } }