BUG #19468: Prevent SIGSEGV on FETCH after ALTER TYPE of cursor rowtype - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      19468
Logged by:          HaoGang Mao
Email address:      haogangmao@gmail.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.