public inbox for [email protected]  

help / color / mirror / Atom feed

From: Srinath Reddy Sadipiralla <[email protected]>
To: [email protected]
To: [email protected]
Subject: Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a prepared statement returns a composite type cast t
Date: Mon, 4 May 2026 00:41:50 +0530
Message-ID: <CAFC+b6oVzoiWuecSOapBqfur1Cf0a4oXcB4kmmwjDRytQxs1wQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Hi,

On Sat, May 2, 2026 at 1:27 AM PG Bug reporting form <[email protected]>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      19470
> Logged by:          HaoGang Mao
> Email address:      [email protected]
> 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/

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a prepared statement returns a composite type cast t
  In-Reply-To: <CAFC+b6oVzoiWuecSOapBqfur1Cf0a4oXcB4kmmwjDRytQxs1wQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox