Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wHKGr-0073tH-1S for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Apr 2026 11:37:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wHKGq-00DqN6-2b for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Apr 2026 11:37:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wHIaS-00DLn9-2L for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 09:49:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wHIaQ-00000003JZB-2rPP for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 09:49:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=KmaVAAIkKOJGwoZgnR9vbEK7gACH9YVRoINlp4HsbFg=; b=BtYIiNxBbo/BfM+OwaOiFXJEdK 6AeM1DHXL5UlSrE6wlJGsBU1cHbzc7zET1huf2Z2hbPT7U1hymvxRVl48zAsrCkhL+IOIJ91MNgHN jhT7sWndioSw/XnImcf2B30ZBN697O3iWCgVqBgsID8R2KJ4UT1+hHoNlqBUEpCAL44smSao5AFqj sd3Y3KYaY8mfsWWQ+258hMybcDRYtPdxqPiG5Tc0WGU5RoxX6nYECYN5l15AXt5FtKPKsuz80U7bu eePQVvbBSpkBMDQBZ04hVkyLvPLJdGVPUE5nIckOthesFknKiBymPyhBaUysPgqPV/cpB4AmJJumX h0LpBCmA==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wHIaO-009BTU-2p for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 09:49:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wHIaM-002mEv-2Z for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 09:49:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19468: Prevent SIGSEGV on FETCH after ALTER TYPE of cursor rowtype To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: haogangmao@gmail.com Reply-To: haogangmao@gmail.com, pgsql-bugs@lists.postgresql.org Date: Mon, 27 Apr 2026 09:48:53 +0000 Message-ID: <19468-f4d360e16882e6c0@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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: =20 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=3D0x58365637774c) at varlena.c:234 len =3D 268435452 #2 textout(fcinfo=3D0x7ffc86929ea0) at varlena.c:603 #3 FunctionCall1Coll(flinfo=3D0x5836562990e8, collation=3D0, arg1=3D96990397953868) at fmgr.c:1139 #4 OutputFunctionCall(flinfo=3D0x5836562990e8, val=3D96990397953868) at fmgr.c:1685 #5 record_out(fcinfo=3D0x7ffc8692a040) at rowtypes.c:435 column_type =3D 25 attr =3D 96990397953868 tupdesc =3D 0x7a722c7562a8 ncolumns =3D 2 i =3D 1 #8 printtup(slot=3D0x583656298ff8, self=3D0x58365626f9c0) at printtup.c:360 #9 RunFromStore(portal=3D0x5836562ee740, direction=3DForwardScanDirection, count=3D0, dest=3D0x58365626f9c0) at pquery.c:1094 #10 PortalRunSelect(portal=3D0x5836562ee740, forward=3Dtrue, count=3D0, dest=3D0x58365626f9c0) at pquery.c:917 #11 PortalRun(portal=3D0x5836562ee740, count=3D9223372036854775807, isTopLevel=3Dtrue, dest=3D0x58365626f9c0, altdest=3D0x58365626f9c0, qc=3D0x7ffc8692a3c0) at pquery.c:765 #12 exec_simple_query(query_string=3D0x58365626eb80 "FETCH c;") at postgres.c:1273 #13 PostgresMain(dbname=3D0x5836562a7f38 "postgres", username=3D0x5836562a7f20 "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.