From: Tom Lane <tgl@sss.pgh.pa.us>
To: wangsiyan2@huawei.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19085: Using EXECUTE to run a multi-statement SQL string
 causes an assertion failure
In-reply-to: <19085-3e215c0d39d3f674@postgresql.org>
References: <19085-3e215c0d39d3f674@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 14 Oct 2025 03:59:49 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <894011.1760420045.1@sss.pgh.pa.us>
Date: Tue, 14 Oct 2025 01:34:05 -0400
Message-ID: <894012.1760420045@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/894012.1760420045%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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