Re: Unexpected results from CALL and AUTOCOMMIT=off

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Victor Yegorov <vyegorov(at)gmail(dot)com>, Pierre Forstmann <pierre(dot)forstmann(at)gmail(dot)com>
Subject: Re: Unexpected results from CALL and AUTOCOMMIT=off
Date: 2024-06-04 18:28:43
Message-ID: 538151.1717525723@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

Attachment Content-Type Size
fix-call-in-atomic-context-v1.patch text/x-diff 7.2 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2024-06-04 18:55:15 Re: Purpose of pg_dump tar archive format?
Previous Message Erik Wienhold 2024-06-04 18:07:03 Re: Bugs details.

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-06-04 19:39:23 use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
Previous Message Erik Wienhold 2024-06-04 18:08:05 Re: plpgsql: fix parsing of integer range with underscores