Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>,
feichanghong <feichanghong@qq.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-09-18T04:29:28Z
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, 18 Sept 2025 at 16:19, David Rowley <dgrowleyml@gmail.com> wrote: > > On Thu, 18 Sept 2025 at 16:11, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. > > The issue was introduced in v18 dev cycle, so it's never been a > problem in any production build of Postgres. I could get more on board > with an argument for noting these down if it were some long-standing > well known issue that had been around for several years which we > debated how to fix, and finally did. This isn't that, so IMO, noting > down the bug number is pretty pointless. Just further to that, while I'm on a rant. It's just not a sustainable practice to note down the bug numbers. If we did that for every fix the code and tests would be strewn with random and pretty meaningless bug numbers. It wouldn't inspire much confidence to the casual reader of the code either as it would appear mostly to be a patchwork of fixes. We do have a reputation for good quality. I don't think we need to put up signs anywhere that indicate mistakes once existed here, especially for ones that existed in no released version of PostgreSQL. David