Intermittent Assert("plan->magic == _SPI_PLAN_MAGIC") in 027_stream_regress

Hi,

While testing an unrelated patch I hit an intermittent assertion failure
in recovery/027_stream_regress on master. It reproduces on an
unmodified tree, so I am reporting it separately.

master @ 9e17d25e79d
Linux x86_64, Ubuntu 26.04, gcc 15.2.0
meson, --buildtype=debug -Dcassert=true -Dtap_tests=enabled
-Dreadline=disabled

Failure:

TRAP: failed Assert("plan->magic == _SPI_PLAN_MAGIC"),
File: "../src/backend/executor/spi.c", Line: 1951, PID: 59545
LOG: client backend (PID 59545) was terminated by signal 6: Aborted
DETAIL: Failed process was running: UPDATE temporal_mltrng
SET valid_at = datemultirange(daterange('2016-02-01','2016-03-01'))
WHERE id = '[5,6)'
AND valid_at = datemultirange(daterange('2018-02-01','2018-03-01'));
LOG: terminating any other active server processes
LOG: shutting down because "restart_after_crash" is off

The statement is from src/test/regress/sql/without_overlaps.sql, which
runs in the same parallel group as create_role and generated_virtual
(parallel_schedule line 79). spi.c:1951 is the Assert at the top of
SPI_plan_is_valid(), so something is calling it with a plan that is no
longer a valid SPI plan.

Because the backend dies mid-schedule, every later test in the run is
reported as failed and the standby check fails too; the assert itself is
the only real failure.

Reproduction:

meson test -C build "recovery/027_stream_regress"

It is a race, so it needs a few attempts. Removing
build/testrun/recovery/027_stream_regress between runs is necessary --
otherwise testwrap fails in shutil.rmtree() on the leftovers from the
crashed run and the next attempt aborts in under a second.

Observed rates, running each attempt from a clean testrun directory:

master @ 9e17d25e79d 7 of 20 runs (35%)
c36a0df195d (2026-08-20) 4 of 8 runs (50%)

I first suspected the RI fast-path series (6fc2a486417, e2c812f1475,
2c45694a240, c62b330912e), since temporal foreign keys go through the RI
code. That does not hold up: c36a0df195d predates the first of those
commits and still fails. So the problem is older than that series. I
have not bisected further.

Caveats on the numbers: the 8-run batch at c36a0df195d also produced 4
failures of a different kind, which I believe were the leftover-directory
problem above rather than the assert, so treat that 50% as rough. The
master figure is the more reliable of the two.

I did not manage to capture a backtrace -- core dumps are routed through
apport on this machine and the race is awkward to catch under gdb. I am
happy to try again with guidance on what would be most useful, or to
test a patch.

Regards,
Trakshan Mishra