Skip to content

Retry the DuckDB trim test when a parallel test holds the trim lock - #4415

Merged
erikdarlingdata merged 1 commit into
devfrom
fix/4262-trim-test-evicts
Sep 26, 2026
Merged

erikdarlingdata merged 1 commit into
devfrom
fix/4262-trim-test-evicts

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

Test-only.

RunMemoryTrimCycle_AfterWideRead_ReducesProcessMemory failed on a CI run with DuckDB's reported memory unchanged across the trim (105906176 before and after).

RunMemoryTrimCycle takes the process-wide s_dbLock with TryEnterWriteLock(0). It skips the cycle rather than block when another writer holds the lock, by design, so a live timer never stalls an archival. The lock is static across every DuckDbInitializer, so a test running in parallel that holds it makes this test's trim skip silently. A standalone repro with no contention trimmed every time over 50 iterations.

The test now retries the trim cycle, up to 20 times 50 ms apart, until usage is at or below the trim target. The contract is unchanged: usage must start above the 64 MB target and end at or below it. A trim that never releases memory still fails.

No CHANGELOG entry: test-only.

@erikdarlingdata
erikdarlingdata marked this pull request as ready for review September 26, 2026 13:07
@erikdarlingdata
erikdarlingdata merged commit 9e41518 into dev Sep 26, 2026
15 of 16 checks passed
@erikdarlingdata
erikdarlingdata deleted the fix/4262-trim-test-evicts branch September 26, 2026 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant