Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a prepared statement returns a composite type cast t

Hi,

On Sat, May 2, 2026 at 1:27 AM PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19470
> Logged by: HaoGang Mao
> Email address: haogangmao(at)gmail(dot)com
> PostgreSQL version: 18.3
> Operating system: Linux
> Description:
>
> Reproduction steps (minimal):
> BEGIN;
> CREATE TYPE foo AS (a int, b text);
> PREPARE p AS SELECT CAST(ROW(1, 'hello') AS foo)::text;
> EXECUTE p;
> ALTER TYPE foo ALTER ATTRIBUTE a TYPE VARCHAR(100);
> EXECUTE p;
> COMMIT;
>
> Expected: Error message (type modified while a prepared plan / expression
> is
> active)
> Actual: Server connection dropped; backend aborts with SIGABRT due to
> assertion failure
>
> Server log (trimmed):
> TRAP: failed Assert("false"), File: "heaptuple.c", Line: 1417, PID: <pid>
> ... heap_deform_tuple()
>

Thanks for reporting and the repro, I was able to reproduce this.
The cause of this crash is a cache invalidation failure. When ALTER TYPE is
executed,
the cached plan for the prepared statement is not properly invalidated. So
the executor uses
a stale memory layout during the second execution. This causes tuple
deformation to see type
confusion, reading a 4-byte INT as a Varlena header. The system interprets
the lowest byte
of the integer as a TOAST pointer, reads the adjacent garbage memory as a
TOAST tag,
and triggers the Assert(false) in VARTAG_SIZE, replacing the assertion with
an elog(ERROR)
would prevent the hard crash, it only masks the main issue. I think the
correct fix is that
ALTER TYPE on a composite attribute correctly triggers a plan
re-validation, thoughts?

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/