Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

array_userfuncs.c

Blame
    • Tom Lane's avatar
      18c0b4ec
      Fix array- and path-creating functions to ensure padding bytes are zeroes. · 18c0b4ec
      Tom Lane authored
      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.
      18c0b4ec
      History
      Fix array- and path-creating functions to ensure padding bytes are zeroes.
      Tom Lane authored
      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.