Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc
Date
Msg-id YNGEbIz5iVqRzIhJ@paquier.xyz
Whole thread Raw
In response to Assertion failure in HEAD and 13 after calling COMMIT in a stored proc  (Jim Nasby <nasbyj@amazon.com>)
Responses Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc
List 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

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Doc chapter for Hash Indexes
Next
From: Noah Misch
Date:
Subject: Re: intermittent failures in Cygwin from select_parallel tests