Skip site navigation (1) Skip section navigation (2)

Re: Alignment padding bytes in arrays vs the planner

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Alignment padding bytes in arrays vs the planner
Date: 2011-04-27 15:56:51
Message-ID: 16775.1303919811@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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:

	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

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-04-27 15:58:31
Subject: Re: unknown conversion %m
Previous:From: Tom LaneDate: 2011-04-27 15:44:30
Subject: Re: Alignment padding bytes in arrays vs the planner

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group