Noah Misch <noah(at)leadboat(dot)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:
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
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2011-04-27 15:58:31|
|Subject: Re: unknown conversion %m|
|Previous:||From: Tom Lane||Date: 2011-04-27 15:44:30|
|Subject: Re: Alignment padding bytes in arrays vs the planner |