MIME-Version: 1.0
References: <19470-0a344a5b356fc1a8@postgresql.org>
In-Reply-To: <19470-0a344a5b356fc1a8@postgresql.org>
From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Date: Mon, 4 May 2026 00:41:50 +0530
Message-ID: <CAFC+b6oVzoiWuecSOapBqfur1Cf0a4oXcB4kmmwjDRytQxs1wQ@mail.gmail.com>
Subject: Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a
 prepared statement returns a composite type cast t
To: haogangmao@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d7590c0650ee969c"
Archived-At: <https://www.postgresql.org/message-id/CAFC%2Bb6oVzoiWuecSOapBqfur1Cf0a4oXcB4kmmwjDRytQxs1wQ%40mail.gmail.com>
Precedence: bulk

--000000000000d7590c0650ee969c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sat, May 2, 2026 at 1:27=E2=80=AFAM PG Bug reporting form <noreply@postg=
resql.org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      19470
> Logged by:          HaoGang Mao
> Email address:      haogangmao@gmail.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: <pi=
d>
>   ... 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?


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

--000000000000d7590c0650ee969c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 2, 2=
026 at 1:27=E2=80=AFAM PG Bug reporting form &lt;<a href=3D"mailto:noreply@=
postgresql.org">noreply@postgresql.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">The following bug has been logged on =
the website:<br>
<br>
Bug reference:=C2=A0 =C2=A0 =C2=A0 19470<br>
Logged by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HaoGang Mao<br>
Email address:=C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:haogangmao@gmail.com" =
target=3D"_blank">haogangmao@gmail.com</a><br>
PostgreSQL version: 18.3<br>
Operating system:=C2=A0 =C2=A0Linux<br>
Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>
<br>
Reproduction steps (minimal):<br>
=C2=A0 BEGIN;<br>
=C2=A0 CREATE TYPE foo AS (a int, b text);<br>
=C2=A0 PREPARE p AS SELECT CAST(ROW(1, &#39;hello&#39;) AS foo)::text;<br>
=C2=A0 EXECUTE p;<br>
=C2=A0 ALTER TYPE foo ALTER ATTRIBUTE a TYPE VARCHAR(100);<br>
=C2=A0 EXECUTE p;<br>
=C2=A0 COMMIT;<br>
<br>
Expected: Error message (type modified while a prepared plan / expression i=
s<br>
active)<br>
Actual:=C2=A0 =C2=A0Server connection dropped; backend aborts with SIGABRT =
due to<br>
assertion failure<br>
<br>
Server log (trimmed):<br>
=C2=A0 TRAP: failed Assert(&quot;false&quot;), File: &quot;heaptuple.c&quot=
;, Line: 1417, PID: &lt;pid&gt;<br>
=C2=A0 ... heap_deform_tuple()<br></blockquote><div><br>Thanks for reportin=
g and the repro, I was able to reproduce this.<br>The cause of this crash i=
s a cache invalidation failure. When ALTER TYPE is executed,<br>the cached =
plan for the prepared statement is not properly invalidated. So the executo=
r uses<br>a stale memory layout during the second execution. This causes tu=
ple deformation to see type<br>confusion, reading a 4-byte INT as a Varlena=
 header. The system interprets the lowest byte<br>of the integer as a TOAST=
 pointer, reads the adjacent garbage memory as a TOAST tag,<br>and triggers=
 the Assert(false) in VARTAG_SIZE, replacing the assertion with an elog(ERR=
OR)<br>would prevent the hard crash, it only masks the main issue. I think =
the correct fix is that<br>ALTER TYPE on a composite attribute correctly tr=
iggers a plan re-validation, thoughts?</div></div><div><br clear=3D"all"></=
div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><br><di=
v dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"col=
or:rgb(34,34,34)">Thanks,</span><br style=3D"color:rgb(34,34,34)"><span sty=
le=3D"color:rgb(34,34,34)">Srinath Reddy Sadipiralla</span><br style=3D"col=
or:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">EDB:=C2=A0</span><a h=
ref=3D"https://www.enterprisedb.com/" style=3D"color:rgb(17,85,204)" target=
=3D"_blank">https://www.enterprisedb.com/</a></div></div></div>

--000000000000d7590c0650ee969c--