• Etsuro Fujita's avatar
    Fix some issues with step generation in partition pruning. · 13838740
    Etsuro Fujita authored
    In the case of range partitioning, get_steps_using_prefix() assumes that
    the passed-in prefix list contains at least one clause for each of the
    partition keys earlier than one specified in the passed-in
    step_lastkeyno, but the caller (ie, gen_prune_steps_from_opexps())
    didn't take it into account, which led to a server crash or incorrect
    results when the list contained no clauses for such partition keys, as
    reported in bug #16500 and #16501 from Kobayashi Hisanori.  Update the
    caller to call that function only when the list created there contains
    at least one clause for each of the earlier partition keys in the case
    of range partitioning.
    
    While at it, fix some other issues:
    
    * The list to pass to get_steps_using_prefix() is allowed to contain
      multiple clauses for the same partition key, as described in the
      comment for that function, but that function actually assumed that the
      list contained just a single clause for each of middle partition keys,
      which led to an assertion failure when the list contained multiple
      clauses for such partition keys.  Update that function to match the
      comment.
    * In the case of hash partitioning, partition keys are allowed to be
      NULL, in which case the list to pass to get_steps_using_prefix()
      contains no clauses for NULL partition keys, but that function treats
      that case as like the case of range partitioning, which led to the
      assertion failure.  Update the assertion test to take into account
      NULL partition keys in the case of hash partitioning.
    * Fix a typo in a comment in get_steps_using_prefix_recurse().
    * gen_partprune_steps() failed to detect self-contradiction from
      strict-qual clauses and an IS NULL clause for the same partition key
      in some cases, producing incorrect partition-pruning steps, which led
      to incorrect results of partition pruning, but didn't cause any
      user-visible problems fortunately, as the self-contradiction is
      detected later in the query planning.  Update that function to detect
      the self-contradiction.
    
    Per bug #16500 and #16501 from Kobayashi Hisanori.  Patch by me, initial
    diagnosis for the reported issue and review by Dmitry Dolgov.
    Back-patch to v11, where partition pruning was introduced.
    
    Discussion: https://postgr.es/m/16500-d1613f2a78e1e090%40postgresql.org
    Discussion: https://postgr.es/m/16501-5234a9a0394f6754%40postgresql.org
    13838740
partprune.c 107 KB