Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
feichanghong <feichanghong@qq.com>,
pgsql-bugs@lists.postgresql.org
Date: 2025-09-18T04:11:00Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix EPQ crash from missing partition pruning state in EState
- 9a82a64edcd8 18.0 landed
- 8741e48e5dda 19 (unreleased) landed
-
Calculate agglevelsup correctly when Aggref contains a CTE.
- b0cc0a71e0a0 19 (unreleased) cited
-
Move PartitionPruneInfo out of plan nodes into PlannedStmt
- bb3ec16e14de 18.0 cited
David Rowley <dgrowleyml@gmail.com> writes: > On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote: >> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart() >> +# Bug #19056 > I don't think it's that useful to note down the bug number that caused > that test to be added. We're inconsistent about whether we do that or not, but it's far from un-heard-of. I just today pushed a patch in which I did mention the bug# in the test case [1], and I did so mostly because the adjacent test case had a similar comment. So I see no reason to object to Amit's usage. > I think it'd be better to write something like: > "Exercise run-time partition pruning code in an EPQ plan" Not expressing an opinion about whether that's better or worse than Amit's lede. regards, tom lane [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b0cc0a71e0a0a760f54c72edb8cd000e4555442b