Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
amit <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, feichanghong <feichanghong@qq.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-09-18T04:56:30Z
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
On Thu, Sep 18, 2025 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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 was just mimicking a few other "cf bug #" mentions in eval-plan-qual.spec, but I'm fine to take it out if we'd prefer to reduce that. Git blame is enough. > > 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. What I added is: # Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart() I'm fine to change the comment to David's suggestion since that makes the test description less narrowly tied to one fix of one specific issue in that path. -- Thanks, Amit Langote