| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>, 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-15 02:53:14 |
| Message-ID: | CAApHDvq5tF3D5Ptd9MFqVqB_RKbyC19tk2m2VijZRKsUN0YgbA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, 11 Oct 2026 at 00:51, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> EPQ EState has another problem, which the initialized flag doesn't
> address: the ExprContext of the PartitionPruneState is created by
> CreatePartitionPruneState() for the parent EState, so exec pruning in
> the EPQ reads the parent's es_param_exec_vals. If the pruning depends
> on a value from the re-fetched row, the EPQ prunes with the value from
> the old row version, and can remove the partition it actually needs.
>
> This isn't caused by 1b5dd3a24. Before it the EPQ re-initialized the
> exec contexts, but with the same parent ExprContext, so this goes back
> to 8741e48e5.
Thanks for finding this and for putting the patch together.
Pushed.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-10-15 02:55:45 | Re: BUG #19488: Standby connection fails after dropping on login event trigger enabled always |
| Previous Message | John Naylor | 2026-10-15 02:44:09 | use-after-free in jsonb_set_lax() |