Re: BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function

Hi,

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

> The following bug has been logged on the website:
>
> Bug reference: 19544
> Logged by: HaoGang Mao
> Email address: haogangmao(at)gmail(dot)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