On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
> 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]
>
> > We've run into other manifestations of this issue before. Awhile ago
> > I made a push to ensure that datatype input functions didn't leave any
> > ill-defined padding bytes in their results, as a result of similar
> > misbehavior for simple constants. But this example shows that we'd
> > really have to enforce the rule of "no ill-defined bytes" for just about
> > every user-callable function's results, which is a pretty ugly prospect.
>
> 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.)
Adding a memory definedness check to printtup() turned up one more culprit:
tsquery_and.