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.
*** a/src/backend/utils/adt/tsquery_util.c --- b/src/backend/utils/adt/tsquery_util.c *************** *** 336,342 **** QTN2QT(QTNode *in) cntsize(in, &sumlen, &nnode); len = COMPUTESIZE(nnode, sumlen); ! out = (TSQuery) palloc(len); SET_VARSIZE(out, len); out->size = nnode; --- 336,342 ---- cntsize(in, &sumlen, &nnode); len = COMPUTESIZE(nnode, sumlen); ! out = (TSQuery) palloc0(len); SET_VARSIZE(out, len); out->size = nnode;
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers