Re: Unexpected results from CALL and AUTOCOMMIT=off

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Victor Yegorov <vyegorov@gmail.com>, Pierre Forstmann <pierre.forstmann@gmail.com>
Date: 2024-06-04T18:28:43Z
Lists: pgsql-hackers, pgsql-general

Attachments

I wrote:
> I poked into this and found that the source of the problem is that
> plpgsql's exec_stmt_call passes allow_nonatomic = true even when
> it's running in an atomic context.  So we can fix it with basically
> a one-line change:

> -	options.allow_nonatomic = true;
> +	options.allow_nonatomic = !estate->atomic;

> I'm worried about whether external callers might've made a comparable
> mistake, but I think all we can do is document it a little better.
> AFAICS there isn't any good way for spi.c to realize that this mistake
> has been made, else we could have it patch up the mistake centrally.

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.

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

			regards, tom lane

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.