Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc
От | Tom Lane |
---|---|
Тема | Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc |
Дата | |
Msg-id | 1730209.1624373922@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc
|
Список | 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
В списке pgsql-hackers по дате отправления: