Re: Oversight in reparameterize_path_by_child leading to executor crash
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-09-11T02:05:36Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Postpone reparameterization of paths until create_plan().
- b7e2121ab7d6 17.0 landed
-
Apply band-aid fix for an oversight in reparameterize_path_by_child.
- e031995d5c26 14.11 landed
- 7af96a66f43c 13.14 landed
- 62f120203147 16.2 landed
- 2e822a1d62d0 12.18 landed
- 12ec16d11c8b 15.6 landed
On Fri, Sep 8, 2023 at 3:04 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > When the clause s.t1b = s.a is presented to distribute_qual_to_rels() > it has form PHV(t1.b) = t2.b. The PHV's ph_eval_at is 4, which is what > is returned as varno to pull_varnos(). The other Var in the caluse has > varno = 4 already so pull_varnos() returns a SINGLETON relids (b 4). > The clause is an equality clause, so it is used to create an > Equivalence class. > generate_base_implied_equalities_no_const() then constructs the same > RestrictInfo again and adds to baserestrictinfo of Rel with relid = 4 > i.e. t2's baserestrictinfo. I don't know whether that's the right > thing to do. Well, I think that's what PHVs are supposed to do. Quoting the README: ... Note that even with this restriction, pullup of a LATERAL subquery can result in creating PlaceHolderVars that contain lateral references to relations outside their syntactic scope. We still evaluate such PHVs at their syntactic location or lower, but the presence of such a PHV in the quals or targetlist of a plan node requires that node to appear on the inside of a nestloop join relative to the rel(s) supplying the lateral reference. > I am not sure where we are taking the original bug fix with this > investigation. Is it required to fix this problem in order to fix the > original problem OR we should commit the fix for the original problem > and then investigate this further? Fair point. This seems a separate problem from the original, so I'm okay we fix them separately. Thanks Richard