BUG #19468: Prevent SIGSEGV on FETCH after ALTER TYPE of cursor rowtype

The following bug has been logged on the website:

Bug reference: 19468
Logged by: HaoGang Mao
Email address: haogangmao(at)gmail(dot)com
PostgreSQL version: 17.3
Operating system: OS: Linux (Docker)
Description:

Summary:
PostgreSQL crashes with SIGSEGV when a cursor is open over a composite
type and the type is modified via ALTER TYPE during the same transaction,
followed by a second FETCH.

Reproduction steps (minimal):
CREATE TYPE foo AS (a INT, b INT);
BEGIN;
DECLARE c CURSOR FOR
SELECT (i, power(2, 30))::foo
FROM generate_series(1,10) i;
FETCH c;
ALTER TYPE foo ALTER ATTRIBUTE b TYPE TEXT;
FETCH c;
COMMIT;

Expected: Error message (type modified during active cursor)
Actual: Server process terminated with signal 11 (Segmentation fault)

Confirmed environment:
PostgreSQL 18.3, built from source with --enable-cassert --enable-debug
Docker image: sqleek-pg18-debug:18.3
Reproduction / stack script: report/postgres/get_stack3.sh
Full stack output: report/postgres/crash_stack4.txt

Server log:
client backend (PID 58) was terminated by signal 11: Segmentation fault
Failed process was running: FETCH c;

GDB backtrace (trimmed):
Program received signal SIGSEGV, Segmentation fault.
#0 0x00007a7236074c60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 text_to_cstring(t=0x58365637774c) at varlena.c:234
len = 268435452
#2 textout(fcinfo=0x7ffc86929ea0) at varlena.c:603
#3 FunctionCall1Coll(flinfo=0x5836562990e8, collation=0,
arg1=96990397953868) at fmgr.c:1139
#4 OutputFunctionCall(flinfo=0x5836562990e8,
val=96990397953868) at fmgr.c:1685
#5 record_out(fcinfo=0x7ffc8692a040) at rowtypes.c:435
column_type = 25
attr = 96990397953868
tupdesc = 0x7a722c7562a8
ncolumns = 2
i = 1
#8 printtup(slot=0x583656298ff8, self=0x58365626f9c0)
at printtup.c:360
#9 RunFromStore(portal=0x5836562ee740,
direction=ForwardScanDirection, count=0,
dest=0x58365626f9c0) at pquery.c:1094
#10 PortalRunSelect(portal=0x5836562ee740, forward=true,
count=0, dest=0x58365626f9c0) at pquery.c:917
#11 PortalRun(portal=0x5836562ee740,
count=9223372036854775807, isTopLevel=true,
dest=0x58365626f9c0, altdest=0x58365626f9c0,
qc=0x7ffc8692a3c0) at pquery.c:765
#12 exec_simple_query(query_string=0x58365626eb80 "FETCH c;")
at postgres.c:1273
#13 PostgresMain(dbname=0x5836562a7f38 "postgres",
username=0x5836562a7f20 "pguser") at postgres.c:4766

Stack note:
The crash happens while returning the second FETCH result. record_out()
uses the modified composite type output path and calls textout() on a
value that still has the old INT representation, leading to an invalid
text datum length before the SIGSEGV.

psql output:
CREATE TYPE
BEGIN
DECLARE CURSOR
row
----------------
(1,1073741824)
(1 row)

ALTER TYPE
psql:/tmp/trigger.sql:14: server closed the connection unexpectedly
psql:/tmp/trigger.sql:14: error: connection to server was lost

Hypothesis:
The cursor holds a reference to the tuple descriptor for type "foo".
After ALTER TYPE modifies the type, the descriptor may be invalidated
while the cursor still holds a dangling pointer to it. The second FETCH
dereferences data using the new descriptor/output function metadata.