Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-08-19T17:11:00Z
Lists: pgsql-bugs
On 19/8/2024 18:36, Tom Lane wrote: > Andrei Lepikhov <lepihov@gmail.com> writes: >> Thanks for pushing this! > >> But could you change this code a little bit? >> I reported this issue a year ago. At that time, it was triggered by the >> CustomScan node [1]. I haven't found the solution there [2]. Your code >> looks like a good tradeoff, and if you slightly change the code (like in >> the attachment), it allows CustomScan to survive such cases. > > This seems like it's making assumptions it shouldn't about what > CustomScan does. If there's an argument for doing this, it should > be added to the adjacent comments. Hm, I got into this problem many times using CustomScan node. Do you have some objections to not allow CustomScan node have a RECORD Var in the target list? For example, once I got this bug designing CustomScan which gathered lightweight statistics on-the-fly under a Sort and GROUP-BY nodes. I didn't change any tuple and had the same target list as the child node. Why we should analyse target list and don't use CustomScan if it contains Var of specific type? > > (Also, what's with the random change in contrib/Makefile?) Oops, it's a waste code, pardon. -- regards, Andrei Lepikhov
Commits
-
Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.
- b919a97a6cd2 18.0 landed
- 81a12a447753 17.0 landed
- 7408772de563 12.21 landed
- 3ad35d5022c9 13.17 landed
- 120dd033761d 14.14 landed
- 12010f414615 15.9 landed
- 03f679475d9a 16.5 landed
-
Make the upper part of the planner work by generating and comparing Paths.
- 3fc6e2d7f5b6 9.6.0 cited