From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Alignment padding bytes in arrays vs the planner |
Date: | 2011-05-24 18:05:33 |
Message-ID: | BANLkTikhcZBOYvTArWGSrMXZY8FFAGQ6NA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-05-24 18:11:52 | Re: Alignment padding bytes in arrays vs the planner |
Previous Message | Heikki Linnakangas | 2011-05-24 18:02:40 | Re: "errno" not set in case of "libm" functions (HPUX) |