Skip to content

Add per-catalog active partition count limit#89

Merged
imp merged 2 commits into
mainfrom
fmurphy/active-partition-cap
Jun 30, 2026
Merged

Add per-catalog active partition count limit#89
imp merged 2 commits into
mainfrom
fmurphy/active-partition-cap

Conversation

@AnIrishDuck

Copy link
Copy Markdown
Collaborator

Introduce max_active_partitions config (default 256) enforced alongside the existing max_partition_bytes limit in prune_topics. When the number of active (in-memory, writable) partitions across the catalog exceeds the limit, the oldest active partitions are closed until the count is back within bounds, mirroring the byte-based pruning.

Also fix the pruning ages map, which was keyed solely on segment end time: partitions sharing an end time collided and overwrote each other, hiding them from both the byte and active-count limits. The key now includes the topic and partition names as tiebreakers.

Claude-Session: https://claude.ai/code/session_01Dcvvv5f1pihsE6gDaETRid

@AnIrishDuck AnIrishDuck requested review from JONBRWN and imp June 26, 2026 18:25
claude added 2 commits June 30, 2026 19:16
Introduce `max_active_partitions` config (default 4096) enforced
alongside the existing `max_partition_bytes` limit in `prune_topics`.
When the number of active (in-memory, writable) partitions across the
catalog exceeds the limit, the oldest active partitions are closed
until the count is back within bounds, mirroring the byte-based pruning.

Also fix the pruning `ages` map, which was keyed solely on segment end
time: partitions sharing an end time collided and overwrote each other,
hiding them from both the byte and active-count limits. The key now
includes the topic and partition names as tiebreakers.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Dcvvv5f1pihsE6gDaETRid
Reconcile classified segments using the in-memory `sealed_ix` watermark,
reading it via `get_topic`/`get_partition` — which lazily *loads* the
partition. A freshly loaded partition reports `sealed_ix == None`, so
every one of its on-disk segments fell into the informational "active"
bucket. This inflated the reported `active_segments` count: each cold or
evicted partition contributed all of its segments, even though a closed
partition's tail is immutable (a reopen begins a brand-new segment at
`max_segment + 1`, so nothing ever appends to the persisted tail again).

Classify each partition without loading it: a non-resident partition is
quiescent and all its persisted segments are sealed, while a resident
partition keeps the conservative watermark semantics so its live active
tail (and any in-flight roll) still lands in the active bucket. Add a
non-loading `Catalog::resident_sealed_ix` / `Topic::resident_sealed_ix`
lookup and a `SealStatus` classification for the pass.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Dcvvv5f1pihsE6gDaETRid
@imp imp force-pushed the fmurphy/active-partition-cap branch from a97ef7f to 2ad79e9 Compare June 30, 2026 16:16
@imp imp merged commit 0c64645 into main Jun 30, 2026
7 of 8 checks passed
@imp imp deleted the fmurphy/active-partition-cap branch June 30, 2026 16:26
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.

3 participants