]> granicus.if.org Git - postgresql/commit
Fix valgrind's "unaddressable bytes" whining about BRIN code.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 26 May 2015 01:56:19 +0000 (21:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 26 May 2015 01:56:19 +0000 (21:56 -0400)
commit79f2b5d583e2e2a7ccd13e31d0e20a900c8f2f61
tree2d8ce54ca61d62de014d84a4e66cb9fb8d231fdc
parent3503003eb70c5a56c59afb20b4c7abec6cf9eb86
Fix valgrind's "unaddressable bytes" whining about BRIN code.

brin_form_tuple calculated an exact tuple size, then palloc'd and
filled just that much.  Later, brin_doinsert or brin_doupdate would
MAXALIGN the tuple size and tell PageAddItem that that was the size
of the tuple to insert.  If the original tuple size wasn't a multiple
of MAXALIGN, the net result would be that PageAddItem would memcpy
a few more bytes than the palloc request had been for.

AFAICS, this is totally harmless in the real world: the error is a
read overrun not a write overrun, and palloc would certainly have
rounded the request up to a MAXALIGN multiple internally, so there's
no chance of the memcpy fetching off the end of memory.  Valgrind,
however, is picky to the byte level not the MAXALIGN level.

Fix it by pushing the MAXALIGN step back to brin_form_tuple.  (The other
possible source of tuples in this code, brin_form_placeholder_tuple,
was already producing a MAXALIGN'd result.)

In passing, be a bit more paranoid about internal allocations in
brin_form_tuple.
src/backend/access/brin/brin_pageops.c
src/backend/access/brin/brin_tuple.c