Horton

Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jim Nasby <nasbyj@amazon.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-22T14:58:42Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
>> The following generates an assertion failure.

> A bisect run points me to the following commit:
> commit 73b06cf893c9d3bb38c11878a12cc29407e78b6c
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date:   Fri Nov 22 15:02:18 2019 -0500
> Avoid taking a new snapshot for an immutable simple expression in plpgsql.

Hmm.  I think the real issue here is that commit 84f5c2908 did
not cover the "simple expression" code path in plpgsql.  We
need to re-establish an outer snapshot when the next thing
that happens after COMMIT is a simple expression, too.

In this view, 73b06cf8 just removed code that was masking the
lack of a snapshot during the evaluation of the simple expr
itself.  However, we'd still have had a problem if the simple
expr returned a toast pointer that we had to dereference after
returning (and popping that snapshot).  So I'm thinking
back-patch to v11, as before.

			regards, tom lane

Commits

  1. Restore the portal-level snapshot for simple expressions, too.

  2. Centralize the logic for protective copying of utility statements.

  3. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.

  4. Avoid taking a new snapshot for an immutable simple expression in plpgsql.