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