From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: rekgrpth@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17035: assert after commit
In-reply-to: <20210526174017.GA11909@alvherre.pgsql>
References: <20210526174017.GA11909@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Wed, 26 May 2021 13:40:17 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1549811.1622051273.1@sss.pgh.pa.us>
Date: Wed, 26 May 2021 13:47:53 -0400
Message-ID: <1549812.1622051273@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1549812.1622051273%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Hmm, see for example [1] which is doing SPI_prepare_my() [2] and then
> SPI_execute_plan_my() ... Does the SPI interface really require that you
> create an ActivePortal in the SPI-calling code?

The expectation is that the calling code is already executing inside
some Portal.  If it isn't, it's incumbent on the caller to set up
an adequate substitute environment, in particular a transaction
snapshot.  The only thing 84f5c2908 changed is that now you get
a guaranteed failure if you neglect to provide that, rather than
failing only in corner cases.

Possibly we should change that Assert to an elog that tries to
make it clear that the blame is on the caller.

			regards, tom lane