zeroshade opened a new pull request, #1394: URL: https://github.com/apache/arrow-go/pull/1394
### Rationale for this change `deltaBitPackDecoder` allocated its per-miniblock bit-width buffer (`deltaBitWidths`) from the reader's allocator, but decoders have no `Release`, so the buffer was never returned. This leaks for: - DELTA_BINARY_PACKED int32/int64 columns, and - the temporary length decoders that DELTA_LENGTH_BYTE_ARRAY (one) and DELTA_BYTE_ARRAY (two) create inside `SetData` on every page. With a checked allocator, reading a 545-row binary column back through pqarrow left 64 bytes (DELTA_LENGTH_BYTE_ARRAY) and 128 bytes (DELTA_BYTE_ARRAY) allocated after everything was released, more for multi-page columns. Found while reviewing #1392. ### What changes are included in this PR? `deltaBitWidths` is now a reused `[]byte` on the Go heap, grown only when needed (the same pattern as the decoders' existing `lengthScratch`). The size bound is unchanged: the header validation already caps the miniblock count. No API change. ### Are these changes tested? Yes. `TestDeltaDecodersDoNotRetainAllocations` (in `delta_bit_packing_validation_test.go`) decodes DELTA_BINARY_PACKED, DELTA_LENGTH_BYTE_ARRAY and DELTA_BYTE_ARRAY data with a checked allocator and asserts nothing is left allocated. All three subtests fail on main (`LEAK of 64 bytes`) and pass with the change. - `go test ./parquet/internal/encoding ./parquet/file ./parquet/pqarrow`: ok - `go test -tags noasm ./parquet/internal/encoding` and `GOARCH=386 go test ./parquet/internal/encoding`: ok - `go vet ./parquet/internal/encoding` and `gofmt -l`: clean ### Are there any user-facing changes? No API changes. Readers using a checked or C-backed allocator no longer leak a small buffer per delta-encoded page. -- 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]
