Re: Alignment padding bytes in arrays vs the planner

On Tue, May 24, 2011 at 02:05:33PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 1:12 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > 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.
>
> *squints*
>
> OK, I can't see what's broken. Help?

QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
array of QueryItem, which contains three bytes of padding between its first and
second members. Those bytes don't get initialized, so we have unpredictable
content in the resulting datum.