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

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: haogangmao(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19468: Prevent SIGSEGV on FETCH after ALTER TYPE of cursor rowtype
Date: 2026-04-27 12:12:57
Message-ID: CAJTYsWU6BxT5T_kqdAhnQncGGj0aCR-P1aKQdxexdd3aW_WdiA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Mon, 27 Apr 2026 at 17:03, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> 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
>

Looks the same as [1].

Regards,
Ayush

[1] PostgreSQL: Re: BUG #19466: Server crash (SIGSEGV) when FETCH after
ALTER TYPE during open cursor
<https://www.postgresql.org/message-id/CAJTYsWUJRkCEopx07tSMX8MGcxzf0CJQh3di2XhetquzdiiVOQ%40mail.gmail.com>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message John Naylor 2026-04-27 12:20:21 Re: BUG #19467: Inconsistency in MOD() result involving POWER() and floating-point precision in PostgreSQL
Previous Message Ayush Tiwari 2026-04-27 10:54:55 Re: to_date()/to_timestamp() silently accept month=0 and day=0