morningman opened a new pull request, #67735:
URL: https://github.com/apache/doris/pull/67735
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #67734, #67529
Problem Summary:
Two flaky sql cache suites on branch-4.1. Both fail the same way — a sql
cache entry
that was primed a moment earlier is gone by the time it is asserted — and
both were red
together in p0 build 124525 (`5657 passed / 2 failed`; no crash, no OOM,
unrelated to
the PR that build was testing).
**Root cause.** The FE sql cache is a single Caffeine map shared by every
session
(`NereidsSqlCacheManager.sqlCaches`), 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 admission window holds a single entry and a
just cached
statement is dropped as soon as any other session caches anything.
`SessionVariable.enableSqlCache` defaults to `true`, so the rest of the p0
suite running
concurrently against the same FE is enough. Ordinary LRU pressure is ruled
out: only 15
distinct selects ran cluster wide during the 299ms window in which the
flight suite lost
its entry. Verified against caffeine 3.2.4:
```
maximumSize=100 1 other insert after mine -> survived 7/20
maximumSize=10000 1 other insert after mine -> survived 20/20
```
This is not an FE bug — the cache is best effort and gives no retention
guarantee.
### Changes
**1. `arrow_flight_sql_p0/test_sql_cache_over_arrow_flight`** —
cherry-picked from
#67734. Raise `sql_cache_manage_num` while the suite runs, as the other five
sql cache
suites (`mv_with_sql_cache`, `mtmv_with_sql_cache`,
`parse_sql_from_sql_cache`,
`union_all_compensate`, `union_rewrite_grace_big`) already do, and restore
it afterwards
so the rest of the run does not keep 10000 cached plans alive in the FE
heap. This suite
is identical on master and branch-4.1 and has failed on both.
**2. `query_p0/cache/sql_cache_object_type`** — picks up the hunk that the
#67556
backport missed. Master fixed this in #67529 on 2026-09-04 by replacing the
closing
`assertTrue(hasSqlCache(objectSql))` with a re-prime, but #67556 backported
the original
#67381 version of the file, so branch-4.1 kept the fragile assertion. It has
failed **18
times on branch-4.1 since 2026-09-02** and is currently **muted** in
TeamCity; the three
most recent failures were all branch-4.1 PRs. After this change the file is
byte
identical to master again.
**The TeamCity mute on
`query_p0.cache.sql_cache_object_type.sql_cache_object_type`
should be removed once this lands.**
### Release note
None
### Check List (For Author)
- Test
- [x] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] 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:
- [x] No.
- [ ] Yes.
- Does this need documentation?
- [x] No.
- [ ] Yes.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01Njd8iDxdqc19QbLdNtZ7Pt
--
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]
