Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Jim Nasby <nasbyj@amazon.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-06-22T06:34:20Z
Lists: pgsql-hackers
On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote: > The following generates an assertion failure. Quick testing with start and > stop as well as the core dump shows it’s failing on the execution of > `schema_name := schema_name(i)` immediately after COMMIT, because there’s no > active snapshot. On a build without asserts I get a failure in > GetActiveSnapshot() (second stack trace). This works fine on 12_STABLE, but > fails on 13_STABLE and HEAD. 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. Snapshots would be taken when using non-immutable functions. I'd need to study more this code to grab if we could improve the situation after committing the transaction, but, Tom, shouldn't we enforce a snapshot in the case where the expression has not been prepared for execution in the new XACT, even for the immutable case? It seems to me that this refers to the case where expr_simple_lxid is still invalid, no? -- Michael
Commits
-
Restore the portal-level snapshot for simple expressions, too.
- d102aafb6259 14.0 landed
- 77200c569238 11.13 landed
- 6f1321d5ae8e 13.4 landed
- 29d5d5761aa8 12.8 landed
-
Centralize the logic for protective copying of utility statements.
- 7c337b6b527b 14.0 cited
-
Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.
- 84f5c2908dad 14.0 cited
-
Avoid taking a new snapshot for an immutable simple expression in plpgsql.
- 73b06cf893c9 13.0 cited