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-0073tI-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-00DqN7-2b for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Apr 2026 11:37:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wHJbK-00DaJq-1Y for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 10:54:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wHJbI-0000000311H-1UMD for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 10:54:05 +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=J18ptBmVHFgq+Y7UZ0ZU/IKARmPp1vQvjmgCgdUjhI4=; b=vPvmuJvHf6SrX5Njq4a7eQ1L+Z yEdAo0Z0U+l3fXuEF7YXZ/zgPZm/HfNpEIlaIEPY2/BOrDrTLFpxsDE63B0F8XdQGi+S4DX7RD2cr GHFUlfgQcXQg3ftZ8dlLLWyOGHS4ZU4C6COY7UNngUGflfrSu5H++3IBcRnbcBfRffhUKJxQhIVk1 WjUCNEqWIJ0wcl5XLYp17kv/7fBIvvAV8dXlUcmRazbTA0cLC4SkwzNs0uBKKvUGvPsp0DngSMN+3 UNU77nzpghY0D3LikUCZv0MClyr67cOyk9OAAtStG/XatkRbsVGYMkunwgLTUmtclWQKNukplY5lU tBi/09gw==; 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 1wHJbH-009Cu9-2w for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 10:54:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wHJbG-002pSG-1k for pgsql-bugs@lists.postgresql.org; Mon, 27 Apr 2026 10:54:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19469: 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 10:53:54 +0000 Message-ID: <19469-e7612f56d0e1ce34@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: 19469 Logged by: HaoGang Mao Email address: haogangmao@gmail.com PostgreSQL version: 17.3 Operating system: OS: Linux (Docker) Description: =20 An open cursor can continue returning tuples built with the old physical layout of a named composite type. If that type is changed in the same transaction (for example ALTER TYPE ... ALTER ATTRIBUTE ... TYPE), a later FETCH may format the tuple using updated descriptor and output metadata. Minimal Reproduction SQL: ```sql 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; ```