zeroshade commented on issue #863: URL: https://github.com/apache/arrow-go/issues/863#issuecomment-5501435809
Closing this as not reproducible, based on the analysis in https://github.com/apache/arrow-go/issues/863#issuecomment-4838489974 and the follow-up. To recap the two points, since neither has been contested: 1. The attached reproducer sets `BloomFilterOffset = 0`, so `GetColumnBloomFilter` returns `nil, nil` before it reads the header, allocates a bitset, touches the pool, or registers cleanup. The bloom filter pool path is never exercised by that test. 2. `ResizeNoShrink(0)` does not destroy capacity — it deliberately keeps the capacity and resets only the length, so a later resize of a recycled buffer does not realloc. This is still the behavior on main (`parquet/metadata/cleanup_bloom_filter.go`). The reported `TotalAlloc` figure is cumulative allocation churn rather than retained memory, so on its own it isn't evidence of pool pollution. That said, I don't want to dismiss a real problem if there is one under this. If you can share a reproducer that actually reaches the bloom filter read path (non-zero `BloomFilterOffset`) and still shows the degradation, please reopen or file a new issue and I'll take another look. -- 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]
