Re: Unexpected results from CALL and AUTOCOMMIT=off

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Victor Yegorov <vyegorov@gmail.com>, Pierre Forstmann <pierre.forstmann@gmail.com>
Date: 2024-06-04T20:13:12Z
Lists: pgsql-hackers, pgsql-general
On Tue, Jun 04, 2024 at 02:28:43PM -0400, Tom Lane wrote:
> Actually, after poking around some more I found that there *is* a way
> to deal with this within spi.c: we can make _SPI_execute_plan ignore
> options->allow_nonatomic unless the SPI_OPT_NONATOMIC flag was given
> when connecting.
> 
> I like this better than my first solution because (a) it seems to
> make the allow_nonatomic flag behave in a more intuitive way;
> (b) spi.c gates some other behaviors on SPI_OPT_NONATOMIC, so that
> gating this one too seems more consistent, and (c) this way, we fix
> not only plpgsql but anything that has copied its coding pattern.

+1

> Hence, new patch attached, now with docs and tests.  Barring
> objections I'll push this one.

Should we expand the documentation for SPI_connect_ext() to note that
SPI_execute_extended()/SPI_execute_plan_extended() depend on the flag?

-- 
nathan



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix behavior of stable functions called from a CALL's argument list.