Request a Demo
Home   >   mailing lists

Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows - Mailing list pgsql-bugs

From Andrey Rachitskiy
Subject Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows
Date
Msg-id CAB8bMituD9yuWp1-EOkG7ohLv32zRX0oF=huXrvf-24C89rXvg@mail.gmail.com
Whole thread
In response to Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows
List pgsql-bugs
Tree view

чт, 8 окт. 2026 г. в 13:08, David Rowley <dgrowleyml@gmail.com>:
On Fri, 2 Oct 2026 at 05:16, Andrey Rachitskiy <pl0h0yp1@gmail.com> wrote:
> Skip InitExecPartitionPruneContexts() when es_epq_active is set.  A
> case is added to eval-plan-qual.

uhh, that's a pretty horrible fix. So partition pruning needs to know
what EPQ is now?

I think it would be much better to fix with the attached, which adds
an "initialized" flag to the PartitionPruneState.


Hi David!

Thanks for the review.

Agreed. Skipping on es_epq_active was answering the wrong question.
The invariant is that InitExecPartitionPruneContexts() must not run
twice on a shared PartitionPruneState.
Your initialized flag is the right fix.

LGTM

--
Regards,
Rachitskiy Andrey

pgsql-bugs by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: BUG #19735: `jsonb_object_agg_unique_strict` drops a JSONB `null` value as if it were SQL NULL
Next
From: Rahul
Date:
Subject: Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation