Horton

Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos

David Rowley <dgrowleyml@gmail.com>

View thread
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-18T05:15:52Z
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 →

  1. Fix EPQ crash from missing partition pruning state in EState

  2. Calculate agglevelsup correctly when Aggref contains a CTE.

  3. Move PartitionPruneInfo out of plan nodes into PlannedStmt

On Thu, 18 Sept 2025 at 16:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > ... 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.
>
> I'm a bit bemused by that viewpoint.  There's an enormous fraction of
> our test suite that is exactly memorializing bugs that once existed.
> Maybe there is some reason to distinguish bugs that never made it
> into an official release, but that seems rather weak to me.

Not intending to sound nasty here, but if you're going to convince me
that I'm off track in my line of thought, it's going to have to be
something more convincing than "I just did this today mostly because I
copied an existing adjacent test case".

In my view, the only sense in writing down bug numbers in tests or
code is if there's some chance that we might get tricked into putting
it back the broken way again. Otherwise they just act as tombstones to
the should-be-forgotten past. It's hard to imagine someone being
convinced to rebreak this issue and delete Amit's new test.
Segfaulting is clearly wrong behaviour. Nobody will be convinced
otherwise.

David