zeroshade opened a new pull request, #743: URL: https://github.com/apache/arrow-go/pull/743
## Summary - Eagerly release adaptive bloom filter candidate data buffers when they are pruned during `InsertHash`/`InsertBulk` and after `WriteTo` completes, instead of relying solely on GC cleanup/finalizer. - Fixes the spurious `LEAK of 64 bytes FROM newBloomFilterCandidate` reported in CI ([job log](https://github.com/apache/arrow-go/actions/runs/23766815889/job/69248342762?pr=741)). ## Details The `adaptiveBlockSplitBloomFilter` creates candidate `blockSplitBloomFilter` objects whose data buffers are only freed by a GC cleanup (`runtime.AddCleanup` on Go 1.24+ / `runtime.SetFinalizer` on Go 1.23). In `TestEncryptedBloomFilters`, `TearDownTest` calls `runtime.GC()` twice, but that isn't always sufficient for the full reachability chain (adaptive filter → candidates → bloom filters → cleanup) to be collected and run before the `CheckedAllocator.AssertSize(0)` assertion. This change releases candidate buffers eagerly at two points: 1. **`InsertHash`/`InsertBulk`** – when `slices.DeleteFunc` prunes candidates that exceeded their NDV threshold. 2. **`WriteTo`** – releases all remaining candidate buffers after writing the optimal one. The existing `addCleanup` on each `blockSplitBloomFilter` remains as a safety net. A second `Release()` from the eventual GC cleanup is a safe no-op since the buffer's internal slice is already nil after the first call. -- 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]
