]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix incorrect step generation in HASH partition pruning
authorDavid Rowley <drowley@postgresql.org>
Thu, 12 Oct 2023 06:51:26 +0000 (19:51 +1300)
committerDavid Rowley <drowley@postgresql.org>
Thu, 12 Oct 2023 06:51:26 +0000 (19:51 +1300)
commit6352f1627641025f90423b44716b6ad5f2adb7b6
tree4340b904d72e71c892465fb2e0e0bb34a032817a
parent4ac7635fdbb7dce58898161a1cc5caf40426335f
Fix incorrect step generation in HASH partition pruning

get_steps_using_prefix_recurse() incorrectly assumed that it could stop
recursive processing of the 'prefix' list when cur_keyno was one before
the step_lastkeyno.  Since hash partition pruning can prune using IS
NULL quals, and these IS NULL quals are not present in the 'prefix'
list, then that logic could cause more levels of recursion than what is
needed and lead to there being no more items in the 'prefix' list to
process.  This would manifest itself as a crash in some code that
expected the 'start' ListCell not to be NULL.

Here we adjust the logic so that instead of stopping recursion at 1 key
before the step_lastkeyno, we just look at the llast(prefix) item and
ensure we only recursively process up until just before whichever the last
key is.  This effectively allows keys to be missing in the 'prefix' list.

This change does mean that step_lastkeyno is no longer needed, so we
remove that from the static functions.  I also spent quite some time
reading this code and testing it to try to convince myself that there
are no other issues.  That resulted in the irresistible temptation of
rewriting some comments, many of which were just not true or inconcise.

Reported-by: Sergei Glukhov
Reviewed-by: Sergei Glukhov, tender wang
Discussion: https://postgr.es/m/2f09ce72-315e-2a33-589a-8519ada8df61@postgrespro.ru
Backpatch-through: 11, where partition pruning was introduced.
src/backend/partitioning/partprune.c
src/test/regress/expected/partition_prune.out
src/test/regress/sql/partition_prune.sql