Re: BUG #19085: Using EXECUTE to run a multi-statement SQL string causes an assertion failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: wangsiyan2(at)huawei(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19085: Using EXECUTE to run a multi-statement SQL string causes an assertion failure
Date: 2025-10-14 05:34:05
Message-ID: 894012.1760420045@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The issue is triggered by a PL/pgSQL procedure that dynamically executes a
> multi-statement SQL string via EXECUTE, combining DECLARE CURSOR and FETCH
> (e.g., "DECLARE test_cursor_1_1 CURSOR FOR SELECT * FROM test_table_1; FETCH
> 200 FROM test_cursor_1_1"). This fails with
> Assert(ActiveSnapshot->as_snap->regd_count == 0) in snapmgr.c:754 because
> the snapshot's registration count (regd_count) reaches 2 during SPI's
> multi-statement processing loop.

I cannot reproduce this assertion, either in master or REL_18_STABLE
branch tip. Are you testing community Postgres, or some locally
modified version?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-10-14 06:53:00 RE: Logical replication fails when partition column order differs from parent
Previous Message Michael Paquier 2025-10-14 04:28:07 Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c