PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows

Hi,

A backend process is terminated by SIGSEGV in run-time partition pruning
when a statement contains a FOR UPDATE CTE that has to recheck a
concurrently
updated row (EvalPlanQual) and a separate CTE that updates a partitioned
table
through an Append with run-time pruning. It reproduces on REL_18_6 and on
master.

== Steps to reproduce

Attached epq-prune-repro.sql, run against a freshly initdb'd cluster:

psql -X -d postgres -f epq-prune-repro.sql

It needs contrib/dblink, which it uses to open the second session.

The enable_* settings only force the nested loop plan on these small tables;
we first hit this with a plan the planner picked on its own (Update ->
Nested
Loop -> CTE Scan / Append with run-time pruning).

== Output I got (REL_18_6, built with --enable-cassert; master gives the
same)

psql:

COMMIT
psql:epq-prune-repro.sql:44: ERROR: 08006: server closed the connection
unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
invalid socket
CONTEXT: while executing query on dblink connection named "s2"
LOCATION: dblink_res_error, dblink.c:2863

Server log (log_error_verbosity = verbose):

2026-10-01 14:07:00.975 UTC [13783] LOG: 00000: client backend (PID
13824) was terminated by signal 11: Segmentation fault
2026-10-01 14:07:00.975 UTC [13783] DETAIL: Failed process was running:
WITH inputs AS MATERIALIZED (
... (the session 2 query above)

Backtrace of the backend core (REL_18_6):

#0 ExecEvalExprSwitchContext (state=0x7f7f7f7f7f7f7f7f,
econtext=0xaaaaf14182f0, isNull=0xffffe735e23f) at
../../../src/include/executor/executor.h:440
#1 partkey_datum_from_expr (context=0xaaaaf1418568, expr=0xaaaaf13fb440,
stateidx=0, value=0xffffe735e240, isnull=0xffffe735e23f) at partprune.c:3823
#2 perform_pruning_base_step (context=0xaaaaf1418568,
opstep=0xaaaaf13fb3f0) at partprune.c:3503
#3 get_matching_partitions (context=0xaaaaf1418568,
pruning_steps=0xaaaaf13fb4c0) at partprune.c:881
#4 find_matching_subplans_recurse (prunedata=0xaaaaf14184d0,
pprune=0xaaaaf14184d8, initial_prune=false, validsubplans=0xffffe735e488,
validsubplan_rtis=0x0)
#5 ExecFindMatchingSubPlans (prunestate=0xaaaaf1418480,
initial_prune=false, validsubplan_rtis=0x0) at execPartition.c:2535
#6 choose_next_subplan_locally (node=0xaaaaf143fe58) at nodeAppend.c:584
#7 ExecAppend (pstate=0xaaaaf143fe58) at nodeAppend.c:330
#8 ExecProcNode (node=0xaaaaf143fe58) at
../../../src/include/executor/executor.h:315
#9 ExecNestLoop (pstate=0xaaaaf142d410) at nodeNestloop.c:159
#10 ExecProcNode (node=0xaaaaf142d410) at
../../../src/include/executor/executor.h:315
#11 ExecModifyTable (pstate=0xaaaaf142c260) at nodeModifyTable.c:4280
#12 ExecProcNode (node=0xaaaaf142c260) at
../../../src/include/executor/executor.h:315
...

On master the frames are the same (partprune.c:3841, execPartition.c:2642,
nodeModifyTable.c:4497), also with state=0x7f7f7f7f7f7f7f7f.

== Output I expected

The session 2 statement completes and dblink_get_result returns updated = 8.
That is what the patched build below returns.

== Builds and settings

- REL_18_6, commit 724edf9bde9d356724ad384a2e196edc3c9f80f7:
SELECT version() = PostgreSQL 18.6 on aarch64-unknown-linux-gnu, compiled
by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
- master, commit 42e96cf2fe095c822f76bc94669ea875cb1e3351:
SELECT version() = PostgreSQL 20devel on aarch64-unknown-linux-gnu,
compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
- configure: '--prefix=/pg' '--enable-cassert' '--enable-debug'
'--without-icu' 'CFLAGS=-O0 -g'
plus `make -C contrib/dblink install`. No other deviations from the
installation instructions.
- Cluster: `initdb -A trust`, started with pg_ctl. The only postgresql.conf
change from the
initdb defaults is log_error_verbosity = verbose. No environment
variables set.

Platform: Linux 7.0.12-linuxkit #1 SMP PREEMPT aarch64 (Docker Desktop on
macOS,
Apple silicon), Debian GNU/Linux 13 (trixie), glibc 2.41-12+deb13u4,
gcc 14.2.0-19, 14 CPUs, 23 GiB RAM.

Release builds: with these exact steps the stock postgres:18.6 Docker image
(Debian 18.6-1.pgdg13+2, aarch64) returns 8 and does not crash (3 of 3
runs).

Release builds do crash on the same query shape under concurrent load from
the
Hatchet workflow engine, whose UpdateDurableEventLogEntriesSatisfied query
has
this structure:
- postgres:18.6 (18.6-1.pgdg13+2) under a synthetic load test: a segfault
every few minutes. A core taken with the dbgsym package installed has the
same frames from ExecModifyTable (called from CteScanNext) up to
ExecEvalExprSwitchContext, with frame #0 at 0x000004a00000000c.
- Google Cloud SQL for PostgreSQL 18, production: "terminated by signal 11"
in that query roughly once a day.
- postgres:17.11 under the same synthetic load: no crashes in 9 runs.

Thanks,
Vladimir Savin

--
*This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the sender
immediately by replying to this email and delete it from your system.
Please do not copy, distribute, or take action based on the contents of
this email if you are not the intended recipient. Any unauthorized use or
disclosure of this email's contents is strictly prohibited.*