Skip site navigation (1) Skip section navigation (2)

Re: Alignment padding bytes in arrays vs the planner

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Alignment padding bytes in arrays vs the planner
Date: 2011-04-27 03:51:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.)

> The seemingly-obvious alternative is to teach equal() to use
> type-specific comparison functions that will successfully ignore
> semantically-insignificant bytes in a value's representation.  However
> this answer has got its own serious problems, including performance,
> transaction safety (I don't think we can assume that equal() is always
> called within live transactions) and the difficulty of identifying
> suitable comparison functions.  Not all types have btree comparison
> functions, and for some of the ones that do, btree "equality" does not
> imply that the values are indistinguishable for every purpose, which is
> what we really need from equal().

Doesn't seem promising, indeed.


In response to


pgsql-hackers by date

Next:From: Daniel FarinaDate: 2011-04-27 03:57:14
Subject: Re: "stored procedures" - use cases?
Previous:From: Bruce MomjianDate: 2011-04-27 03:47:52
Subject: Re: maximum digits for NUMERIC

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group