public inbox for [email protected]
help / color / mirror / Atom feedBUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function
3+ messages / 3 participants
[nested] [flat]
* BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function
@ 2026-07-06 13:49 PG Bug reporting form <[email protected]>
0 siblings, 2 replies; 3+ messages in thread
From: PG Bug reporting form @ 2026-07-06 13:49 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 19544
Logged by: HaoGang Mao
Email address: [email protected]
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
```
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function
@ 2026-07-06 17:01 Ayush Tiwari <[email protected]>
parent: PG Bug reporting form <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: Ayush Tiwari @ 2026-07-06 17:01 UTC (permalink / raw)
To: [email protected]; [email protected]
Hi,
On Mon, 6 Jul 2026 at 22:21, PG Bug reporting form <[email protected]>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19544
> Logged by: HaoGang Mao
> Email address: [email protected]
> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function
@ 2026-07-08 18:25 surya poondla <[email protected]>
parent: PG Bug reporting form <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: surya poondla @ 2026-07-08 18:25 UTC (permalink / raw)
To: [email protected]; [email protected]; +Cc: Ayush Tiwari <[email protected]>
Hi Haogangmao, Ayush
Thank you for reporting the bug.
I verified this, and yes, this is the same crash as
https://www.postgresql.org/message-id/19382-4c2060ffee72759b%40postgresql.org
that Ayush mentioned.
I am actively working on that bug, fixed most of the cases. I am exploring
some corner cases that can reproduce the crash and fixing those too.
Regards,
Surya Poondla
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-07-08 18:25 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-06 13:49 BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function PG Bug reporting form <[email protected]>
2026-07-06 17:01 ` Ayush Tiwari <[email protected]>
2026-07-08 18:25 ` surya poondla <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox