From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Jim Nasby <nasbyj(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc |
Date: | 2021-06-22 14:58:42 |
Message-ID: | 1730209.1624373922@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-06-22 15:04:26 | Re: Maintaining a list of pgindent commits for "git blame" to ignore |
Previous Message | Yugo NAGATA | 2021-06-22 14:54:59 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |