Noah Misch <n...@leadboat.com> writes:
> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> [input functions aren't the only problematic source of uninitialized datum
> bytes]
> FWIW, when I was running the test suite under valgrind, these were the
> functions that left uninitialized bytes in datums: array_recv,
> array_set, array_set_slice, array_map, construct_md_array, path_recv.
> If the test suite covers this well, we're not far off. (Actually, I
> only had the check in PageAddItem ... probably needed to be in one or
> two other places to catch as much as possible.)
Hmm. Eyeballing arrayfuncs.c yesterday, I noted the following functions
using palloc where palloc0 would be safer:
array_recv
array_get_slice
array_set
array_set_slice
array_map
construct_md_array
construct_empty_array
The last may not be an actual hazard since I think there are no pad
bytes in its result, but on the other hand palloc0 is cheap insurance
for it. I hadn't looked at the geometry functions but padding in paths
isn't surprising at all.
When dealing with very large arrays, there might be a case to be made
for not using palloc0 but trying to zero just what needs zeroed.
However that looks a bit complicated to get right, and it's not
impossible that it could end up being slower, since it would add
per-element processing to fill pad bytes instead of just skipping over
them. (memset is pretty damn fast on most machines ...) For the moment
I'm just going to do s/palloc/palloc0/ as a reliable and back-patchable
fix --- possibly in future someone will care to look into whether the
other way is a performance win.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
