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

nodeHash.c

Blame
    • Tom Lane's avatar
      8442317b
      Make the overflow guards in ExecChooseHashTableSize be more protective. · 8442317b
      Tom Lane authored
      The original coding ensured nbuckets and nbatch didn't exceed INT_MAX,
      which while not insane on its own terms did nothing to protect subsequent
      code like "palloc(nbatch * sizeof(BufFile *))".  Since enormous join size
      estimates might well be planner error rather than reality, it seems best
      to constrain the initial sizes to be not more than work_mem/sizeof(pointer),
      thus ensuring the allocated arrays don't exceed work_mem.  We will allow
      nbatch to get bigger than that during subsequent ExecHashIncreaseNumBatches
      calls, but we should still guard against integer overflow in those palloc
      requests.  Per bug #5145 from Bernt Marius Johnsen.
      
      Although the given test case only seems to fail back to 8.2, previous
      releases have variants of this issue, so patch all supported branches.
      8442317b
      History
      Make the overflow guards in ExecChooseHashTableSize be more protective.
      Tom Lane authored
      The original coding ensured nbuckets and nbatch didn't exceed INT_MAX,
      which while not insane on its own terms did nothing to protect subsequent
      code like "palloc(nbatch * sizeof(BufFile *))".  Since enormous join size
      estimates might well be planner error rather than reality, it seems best
      to constrain the initial sizes to be not more than work_mem/sizeof(pointer),
      thus ensuring the allocated arrays don't exceed work_mem.  We will allow
      nbatch to get bigger than that during subsequent ExecHashIncreaseNumBatches
      calls, but we should still guard against integer overflow in those palloc
      requests.  Per bug #5145 from Bernt Marius Johnsen.
      
      Although the given test case only seems to fail back to 8.2, previous
      releases have variants of this issue, so patch all supported branches.