MIME-Version: 1.0
References: <19544-a63ef569459e4e1c@postgresql.org>
In-Reply-To: <19544-a63ef569459e4e1c@postgresql.org>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Mon, 6 Jul 2026 22:31:43 +0530
Message-ID: 
 <CAJTYsWXgcMm7YNMAvsGHmsLVJuBu3w5yjDSTXF8iHdJ=b7xn9g@mail.gmail.com>
Subject: Re: BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a
 PL/pgSQL function
To: haogangmao@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000041d8ee0655f43b62"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWXgcMm7YNMAvsGHmsLVJuBu3w5yjDSTXF8iHdJ%3Db7xn9g%40mail.gmail.com>
Precedence: bulk

--00000000000041d8ee0655f43b62
Content-Type: text/plain; charset="UTF-8"

Hi,

On Mon, 6 Jul 2026 at 22:21, PG Bug reporting form <noreply@postgresql.org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      19544
> Logged by:          HaoGang Mao
> Email address:      haogangmao@gmail.com
> PostgreSQL version: 18.3
> Operating system:   Linux
> Description:
>
> A PL/pgSQL function declares a local variable of composite type foo where
> attribute b is INT. Inside the function, the variable is initialized with
> ROW(123, power(2, 30)). The function then changes foo.b from INT to TEXT
> using ALTER TYPE and returns the previously initialized composite value.
> When the caller executes SELECT bar(), PostgreSQL attempts to output the
> returned record using the updated composite type metadata and the backend
> segfaults in the text output path.
>
> Reproduction steps:
>
> ```sql
> DROP FUNCTION IF EXISTS bar();
> DROP TYPE IF EXISTS foo CASCADE;
>
> CREATE TYPE foo AS (a INT, b INT);
>
> CREATE FUNCTION bar() RETURNS RECORD AS $$
> DECLARE
>     r foo := ROW(123, power(2, 30));
> BEGIN
>     ALTER TYPE foo ALTER ATTRIBUTE b TYPE TEXT;
>     RETURN r;
> END;
> $$ LANGUAGE plpgsql;
>
> SELECT bar();
> ```
>
> Expected behavior:
> PostgreSQL should reject the operation or report an error indicating that
> the composite type changed while a value of the old layout is still being
> returned.
>
> Actual behavior:
> The client connection is closed unexpectedly and the PostgreSQL backend
> process terminates with SIGSEGV.
>
> Server log:
>
> ```text
> LOG:  client backend (PID 90) was terminated by signal 11: Segmentation
> fault
> DETAIL:  Failed process was running: SELECT bar();
> LOG:  terminating any other active server processes
> LOG:  all server processes terminated; reinitializing
> ```
>
> GDB backtrace, trimmed:
>
> ```text
> Program received signal SIGSEGV, Segmentation fault.
> #0  0x0000762a0a47fc60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  text_to_cstring(t=0x5c9ae669d6bc) at varlena.c:234
>     len = 268435452
> #2  textout(fcinfo=0x7fff0aabda20) at varlena.c:603
> #3  FunctionCall1Coll(flinfo=0x5c9ae668c148, collation=0,
>                       arg1=101820360414908) at fmgr.c:1139
> #4  OutputFunctionCall(flinfo=0x5c9ae668c148,
>                        val=101820360414908) at fmgr.c:1685
> #5  record_out(fcinfo=0x7fff0aabdbc0) at rowtypes.c:435
>     column_type = 25
>     attr = 101820360414908
>     tupdesc = 0x762a00b61fd8
>     ncolumns = 2
>     i = 1
> #8  printtup(slot=0x5c9ae668bb88, self=0x5c9ae6699e18) at printtup.c:360
> #9  ExecutePlan(queryDesc=0x5c9ae65c3ed0, operation=CMD_SELECT,
>                 sendTuples=true, numberTuples=0,
>                 direction=ForwardScanDirection, dest=0x5c9ae6699e18)
>     at execMain.c:1742
> #12 PortalRunSelect(portal=0x5c9ae6619740, forward=true,
>                     count=0, dest=0x5c9ae6699e18) at pquery.c:921
> #13 PortalRun(portal=0x5c9ae6619740,
>               count=9223372036854775807, isTopLevel=true,
>               dest=0x5c9ae6699e18, altdest=0x5c9ae6699e18,
>               qc=0x7fff0aabdfe0) at pquery.c:765
> #14 exec_simple_query(query_string=0x5c9ae6599b80 "SELECT bar();")
>     at postgres.c:1273
> #15 PostgresMain(dbname=0x5c9ae65d2f38 "postgres",
>                  username=0x5c9ae65d2f20 "pguser") at postgres.c:4766
> ```
>

This looks the same as [1].

Could you please check that thread, patches are posted,
you may review those. I'll spend some time this week on that too.

Regards,
Ayush

[1]
https://www.postgresql.org/message-id/19382-4c2060ffee72759b%40postgresql.org

--00000000000041d8ee0655f43b62
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 Mon, 6 Jul 20=
26 at 22:21, PG Bug reporting form &lt;<a href=3D"mailto:noreply@postgresql=
.org">noreply@postgresql.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">The following bug has been logged on the websit=
e:<br>
<br>
Bug reference:=C2=A0 =C2=A0 =C2=A0 19544<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>
A PL/pgSQL function declares a local variable of composite type foo where<b=
r>
attribute b is INT. Inside the function, the variable is initialized with<b=
r>
ROW(123, power(2, 30)). The function then changes foo.b from INT to TEXT<br=
>
using ALTER TYPE and returns the previously initialized composite value.<br=
>
When the caller executes SELECT bar(), PostgreSQL attempts to output the<br=
>
returned record using the updated composite type metadata and the backend<b=
r>
segfaults in the text output path.<br>
<br>
Reproduction steps:<br>
<br>
```sql<br>
DROP FUNCTION IF EXISTS bar();<br>
DROP TYPE IF EXISTS foo CASCADE;<br>
<br>
CREATE TYPE foo AS (a INT, b INT);<br>
<br>
CREATE FUNCTION bar() RETURNS RECORD AS $$<br>
DECLARE<br>
=C2=A0 =C2=A0 r foo :=3D ROW(123, power(2, 30));<br>
BEGIN<br>
=C2=A0 =C2=A0 ALTER TYPE foo ALTER ATTRIBUTE b TYPE TEXT;<br>
=C2=A0 =C2=A0 RETURN r;<br>
END;<br>
$$ LANGUAGE plpgsql;<br>
<br>
SELECT bar();<br>
```<br>
<br>
Expected behavior:<br>
PostgreSQL should reject the operation or report an error indicating that<b=
r>
the composite type changed while a value of the old layout is still being<b=
r>
returned.<br>
<br>
Actual behavior:<br>
The client connection is closed unexpectedly and the PostgreSQL backend<br>
process terminates with SIGSEGV.<br>
<br>
Server log:<br>
<br>
```text<br>
LOG:=C2=A0 client backend (PID 90) was terminated by signal 11: Segmentatio=
n<br>
fault<br>
DETAIL:=C2=A0 Failed process was running: SELECT bar();<br>
LOG:=C2=A0 terminating any other active server processes<br>
LOG:=C2=A0 all server processes terminated; reinitializing<br>
```<br>
<br>
GDB backtrace, trimmed:<br>
<br>
```text<br>
Program received signal SIGSEGV, Segmentation fault.<br>
#0=C2=A0 0x0000762a0a47fc60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6<b=
r>
#1=C2=A0 text_to_cstring(t=3D0x5c9ae669d6bc) at varlena.c:234<br>
=C2=A0 =C2=A0 len =3D 268435452<br>
#2=C2=A0 textout(fcinfo=3D0x7fff0aabda20) at varlena.c:603<br>
#3=C2=A0 FunctionCall1Coll(flinfo=3D0x5c9ae668c148, collation=3D0,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 arg1=3D101820360414908) at fmgr.c:1139<br>
#4=C2=A0 OutputFunctionCall(flinfo=3D0x5c9ae668c148,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0val=3D101820360414908) at fmgr.c:1685<br>
#5=C2=A0 record_out(fcinfo=3D0x7fff0aabdbc0) at rowtypes.c:435<br>
=C2=A0 =C2=A0 column_type =3D 25<br>
=C2=A0 =C2=A0 attr =3D 101820360414908<br>
=C2=A0 =C2=A0 tupdesc =3D 0x762a00b61fd8<br>
=C2=A0 =C2=A0 ncolumns =3D 2<br>
=C2=A0 =C2=A0 i =3D 1<br>
#8=C2=A0 printtup(slot=3D0x5c9ae668bb88, self=3D0x5c9ae6699e18) at printtup=
.c:360<br>
#9=C2=A0 ExecutePlan(queryDesc=3D0x5c9ae65c3ed0, operation=3DCMD_SELECT,<br=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sendTuples=3Dtrue, =
numberTuples=3D0,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 direction=3DForward=
ScanDirection, dest=3D0x5c9ae6699e18)<br>
=C2=A0 =C2=A0 at execMain.c:1742<br>
#12 PortalRunSelect(portal=3D0x5c9ae6619740, forward=3Dtrue,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 count=
=3D0, dest=3D0x5c9ae6699e18) at pquery.c:921<br>
#13 PortalRun(portal=3D0x5c9ae6619740,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 count=3D922337203685477580=
7, isTopLevel=3Dtrue,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dest=3D0x5c9ae6699e18, alt=
dest=3D0x5c9ae6699e18,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 qc=3D0x7fff0aabdfe0) at pq=
uery.c:765<br>
#14 exec_simple_query(query_string=3D0x5c9ae6599b80 &quot;SELECT bar();&quo=
t;)<br>
=C2=A0 =C2=A0 at postgres.c:1273<br>
#15 PostgresMain(dbname=3D0x5c9ae65d2f38 &quot;postgres&quot;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0username=3D0x=
5c9ae65d2f20 &quot;pguser&quot;) at postgres.c:4766<br>
```<br></blockquote><div><br>This looks the same as [1].<br><br>Could you p=
lease check that thread, patches are posted,<br>you may review those. I&#39=
;ll spend some time this week on that too.<br><br>Regards,<br>Ayush<br><br>=
[1]=C2=A0<a href=3D"https://www.postgresql.org/message-id/19382-4c2060ffee7=
2759b%40postgresql.org">https://www.postgresql.org/message-id/19382-4c2060f=
fee72759b%40postgresql.org</a></div></div></div>

--00000000000041d8ee0655f43b62--