aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/basics.source
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-07-13 20:38:21 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-07-13 20:38:21 -0400
commitd3b642ad99e958475bab4592db0341badfacee56 (patch)
treea05ce7f156ad0e433c01f42dc8ab7dd164cb3bcb /src/tutorial/basics.source
parente8b22a8a2b65a678d38a120bf7b8cadc144cad17 (diff)
downloadpostgresql-d3b642ad99e958475bab4592db0341badfacee56.tar.gz
postgresql-d3b642ad99e958475bab4592db0341badfacee56.zip
Cope with lateral references in the quals of a subquery RTE.
The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder
Diffstat (limited to 'src/tutorial/basics.source')
0 files changed, 0 insertions, 0 deletions