| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | Vladimir Savin <vladimir(at)encord(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows |
| Date: | 2026-10-08 08:08:38 |
| Message-ID: | CAApHDvqXA-fFSFDKdfmUP-MsD22DursxvV7XoDUk=6KwBq5e4A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, 2 Oct 2026 at 05:16, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)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.
Seemingly, this is all fallout from bb3ec16e1. Prior to that, the
EPQ's EState and the main executor one had different
PartitionPruneState as they were created during executor startup by
the Append / MergeAppend nodes. 8741e48e5 fixed one issue with that,
but it turns out there were repercussions to sharing the
PartitionPruneState with the EPQ's EState.
I also created a much smaller isolation test to check this works.
David
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-incorrect-init-of-run-time-pruning-for-EPQ-re.patch | application/octet-stream | 7.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2026-10-08 08:09:26 | Re: BUG #19735: `jsonb_object_agg_unique_strict` drops a JSONB `null` value as if it were SQL NULL |
| Previous Message | John Naylor | 2026-10-08 07:10:15 | Re: BUG #19597: getQuadrant: impossible case is reachable |