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.
