]> granicus.if.org Git - postgresql/commit
Fix array- and path-creating functions to ensure padding bytes are zeroes.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 27 Apr 2011 17:58:54 +0000 (13:58 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 27 Apr 2011 17:58:54 +0000 (13:58 -0400)
commit1391f1fbd150b06b9c06659b2b340f4dd8b30049
tree921a6ba8f8843847dbf84133d32f4ab7e250d9e7
parent049e8b07fa076ac20662180152f122ba59f96f9f
Fix array- and path-creating functions to ensure padding bytes are zeroes.

Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits.  Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston.  We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.

Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary.  In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc.  Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix.  In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.

Back-patch to all supported branches.
src/backend/utils/adt/array_userfuncs.c
src/backend/utils/adt/arrayfuncs.c
src/backend/utils/adt/geo_ops.c