On Mon, May 23, 2011 at 1:12 AM, Noah Misch <n...@leadboat.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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
