Skip to content

v1.4.2 — rebuild measurement blooms at startup

Choose a tag to compare

View all tags
@funkBuild funkBuild released this 25 Aug 08:58
· 40 commits to main since this release
v1.4.2
e58b3a8
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Bug fix

Stale measurement blooms are now repaired at startup, before serving (#3, follow-up to #2 / v1.4.1).

v1.4.1 only scheduled the rebuild "for the next index flush" — but that flush is triggered solely by 16 MB of new-series index entries, close() skipped it when the memtable was empty, and nothing external can force one. On a steady fleet the ≤1.4.0 blooms therefore stayed on disk and scoped queries stayed blind except where a by {} enumeration had happened to warm the bitmap cache.

  • open() rebuilds and persists every measurement's bloom from the persisted postings keys before the HTTP server serves a request (one prefix scan per measurement; seconds for a few thousand).
  • close() always flushes dirty caches (bitmaps, day bitmaps, HLLs, blooms), not only when the memtable has entries.
  • Only the small MEASUREMENT_BLOOM index records are rewritten; TSM/WAL data and postings bitmaps are untouched.

Regression test: PostingsBitmapTest.OpenRepairsStalePersistedBloomImmediately plants a bloom missing a series and asserts a bare open() makes scoped lookups correct with no other activity.

Assets 2
Loading