postgresql/src/test/regress
Tom Lane 689696c711 Fix bitmap AND/OR scans on the inside of a nestloop partition-wise join.
reparameterize_path_by_child() failed to reparameterize BitmapAnd
and BitmapOr paths.  This matters only if such a path is chosen as
the inside of a nestloop partition-wise join, where we have to pass
in parameters from the outside of the nestloop.  If that did happen,
we generated a bad plan that would likely lead to crashes at execution.

This is not entirely reparameterize_path_by_child()'s fault though;
it's the victim of an ancient decision (my ancient decision, I think)
to not bother filling in param_info in BitmapAnd/Or path nodes.  That
caused the function to believe that such nodes and their children
contain no parameter references and so need not be processed.

In hindsight that decision looks pretty penny-wise and pound-foolish:
while it saves a few cycles during path node setup, we do commonly
need the information later.  In particular, by reversing the decision
and requiring valid param_info data in all nodes of a bitmap path
tree, we can get rid of indxpath.c's get_bitmap_tree_required_outer()
function, which computed the data on-demand.  It's not unlikely that
that nets out as a savings of cycles in many scenarios.  A couple
of other things in indxpath.c can be simplified as well.

While here, get rid of some cases in reparameterize_path_by_child()
that are visibly dead or useless, given that we only care about
reparameterizing paths that can be on the inside of a parameterized
nestloop.  This case reminds one of the maxim that untested code
probably does not work, so I'm unwilling to leave unreachable code
in this function.  (I did leave the T_Gather case in place even
though it's not reached in the regression tests.  It's not very
clear to me when the planner might prefer to put Gather below
rather than above a nestloop, but at least in principle the case
might be interesting.)

Per bug #16536, originally from Arne Roland but with a test case
by Andrew Gierth.  Back-patch to v11 where this code came in.

Discussion: https://postgr.es/m/16536-2213ee0b3aad41fd@postgresql.org
2020-07-14 18:56:56 -04:00
..
data Fix full text search to handle NOT above a phrase search correctly. 2020-04-27 12:21:04 -04:00
expected Fix bitmap AND/OR scans on the inside of a nestloop partition-wise join. 2020-07-14 18:56:56 -04:00
input Fix typos. 2020-06-11 15:14:09 +05:30
output Fix typos. 2020-06-11 15:14:09 +05:30
sql Fix bitmap AND/OR scans on the inside of a nestloop partition-wise join. 2020-07-14 18:56:56 -04:00
.gitignore
GNUmakefile Make install-tests target work with vpath builds 2020-05-31 18:33:00 -04:00
Makefile
parallel_schedule Fix crashes with currtid() and currtid2() 2020-06-01 10:32:06 +09:00
pg_regress_main.c
pg_regress.c Revert "Remove reset of testtablespace from pg_regress on Windows" 2020-07-10 17:08:13 +09:00
pg_regress.h
README
regress.c Fix deadlock danger when atomic ops are done under spinlock. 2020-06-18 14:08:32 -07:00
regressplans.sh
resultmap
serial_schedule Fix crashes with currtid() and currtid2() 2020-06-01 10:32:06 +09:00
standby_schedule

Documentation concerning how to run these regression tests and interpret
the results can be found in the PostgreSQL manual, in the chapter
"Regression Tests".