Обсуждение: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
От
PG Bug reporting form
Дата:
The following bug has been logged on the website:
Bug reference: 19466
Logged by: HaoGang Mao
Email address: haogangmao@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:
PostgreSQL version: 18.3
OS: Linux (Docker)
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)
Server log:
client backend (PID 85) was terminated by signal 11: Segmentation fault
Failed process was running: [above SQL]
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 this invalid pointer.
Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
От
Ayush Tiwari
Дата:
Hi,
On Sat, 25 Apr 2026 at 14:34, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 19466
Logged by: HaoGang Mao
Email address: haogangmao@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:
PostgreSQL version: 18.3
OS: Linux (Docker)
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)
Server log:
client backend (PID 85) was terminated by signal 11: Segmentation fault
Failed process was running: [above SQL]
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 this invalid pointer.
I confirmed the crash on master and traced the root cause. EEOP_ROW was the
only rowtype-aware expression step that cached its TupleDesc at init
time without an ExprEvalRowtypeCache guard. When ALTER TYPE changes
an attribute's storage properties (e.g. int to text), the stale
descriptor leads to SIGSEGV.
Attached patch adds the same ExprEvalRowtypeCache check that
EEOP_FIELDSELECT, EEOP_FIELDSTORE_DEFORM, etc. already use. With
the fix the reproducer gets a clean error instead of crashing.
Regards,
Ayush
Вложения
Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
От
Ayush Tiwari
Дата:
Hi,
On Sat, 25 Apr 2026 at 15:45, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi,On Sat, 25 Apr 2026 at 14:34, PG Bug reporting form <noreply@postgresql.org> wrote:The following bug has been logged on the website:
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)
Server log:
client backend (PID 85) was terminated by signal 11: Segmentation fault
Failed process was running: [above SQL]
I confirmed the crash on master and traced the root cause. EEOP_ROW was the
only rowtype-aware expression step that cached its TupleDesc at init
time without an ExprEvalRowtypeCache guard. When ALTER TYPE changes
an attribute's storage properties (e.g. int to text), the stale
descriptor leads to SIGSEGV.
I looked through nearby rowtype-producing paths and found a few more cases
with the same general shape, so I split the proposed fix into two patches:
0001: Detect row type changes in EEOP_ROW expressions
EEOP_ROW was caching the target composite type's TupleDesc at executor
startup and never re-checking it. The patch stores the TypeCacheEntry
pointer and tupDesc_identifier for named composite row results, then
compares the identifier in ExecEvalRow() before forming the composite
Datum. If the type changed, the cursor now reports:
ERROR: row type <type-name> has changed
instead of producing a malformed Datum that can later crash the backend.
0002: Detect row type changes in additional composite result paths
While checking for similar stale TupleDesc reuse, I found the same kind
of guard is also needed for:
- whole-row Vars returning a named composite type
- SQL-language functions returning a whole named composite result
- targetlist SRFs returning named composite results
The second patch adds the same typcache TupleDesc identity check in
those paths and adds regression coverage for cursor/ALTER TYPE/FETCH
cases that previously crashed or could reuse stale layout information.
With these patches, the original repro and the additional repro cases fail
cleanly with "row type ... has changed" errors, and the backend remains
running.
Thoughts?
Regards,
Ayush
Вложения
On Mon, Apr 27, 2026 at 1:37 PM Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote: > > Thoughts? > This bug is the same as the reported in this[1] email message. You may need to check that thread also. [1]: https://www.postgresql.org/message-id/19382-4c2060ffee72759b%40postgresql.org
Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor
От
Ayush Tiwari
Дата:
Hi Jian,
On Mon, 27 Apr 2026 at 18:04, jian he <jian.universality@gmail.com> wrote:
On Mon, Apr 27, 2026 at 1:37 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
>
> Thoughts?
>
This bug is the same as the reported in this[1] email message.
You may need to check that thread also.
[1]: https://www.postgresql.org/message-id/19382-4c2060ffee72759b%40postgresql.org
Thanks for the information! I'll go through that thread and
continue it there post testing that patch.
Regards,
Ayush
Regards,
Ayush