diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2023-03-30 13:24:09 +0200 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2023-03-30 21:06:31 +0200 |
| commit | 589bb816499e98b60aa5c406c409fb27b42b0e39 (patch) | |
| tree | 77e32a7f07f9dc89b390c674e612cbf4637bf17e /src/backend/parser/parse_expr.c | |
| parent | f9054b7a7cd47b93d6a59f15994ce72c51fe1e04 (diff) | |
| download | postgresql-589bb816499e98b60aa5c406c409fb27b42b0e39.tar.gz postgresql-589bb816499e98b60aa5c406c409fb27b42b0e39.zip | |
Fix setrefs.c code for adjusting partPruneInfos
We were transferring partPruneInfos from PlannerInfo into PlannerGlobal
wrong, essentially relying on all of them being transferred, and
adjusting their list indexes based on that. But apparently it's
possible that some of them are skipped, so that strategy leads to a
corrupted execution tree. Instead, adjust each Append/MergeAppend's
partpruneinfo index as we copy from one list to the other, which seems
safer anyway. This requires adjusting the RT offset of the RTE
referenced in each partPruneInfo ahead of actually adjusting the RTE
itself, which seems a bit too ad-hoc.
This problem was introduced by commit ec386948948c. However, it may be
that we no longer require the change introduced there, so perhaps we
should revert both the present commit and that one.
Problem noticed by sqlsmith.
Author: Amit Langote <amitlangote09@gmail.com
Discussion: https://postgr.es/m/CA+HiwqG6tbc2oadsbyyy24b2AL295XHQgyLRWghmA7u_SL1K8A@mail.gmail.com
Diffstat (limited to 'src/backend/parser/parse_expr.c')
0 files changed, 0 insertions, 0 deletions