From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: a.wicht@gmail.com, pgsql-bugs@lists.postgresql.org,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known
 snapshots" with PostGIS geometries
In-reply-to: <20190904105618.j5l6fhyesmprmstf@alap3.anarazel.de>
References: <15990-eee2ac466b11293d@postgresql.org>
 <20190904105618.j5l6fhyesmprmstf@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 04 Sep 2019 03:56:18 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <912289.1620774094.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 May 2021 19:01:34 -0400
Message-ID: <912290.1620774094@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/912290.1620774094%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> This looks like it might be a procedure related bug to me. Peter?

Somebody reported this same bug again today [1] ... why has it still
not been dealt with?

After an admittedly cursory look-around, it seems like the problem
can be stated as "init_toast_snapshot expects that there already
is a transaction snapshot, which there is not because we just
committed and nothing has re-established a transaction snapshot".
So the question is, where shall we force a new transaction snapshot
to be created after a COMMIT/ROLLBACK inside a procedure?

The most localized fix would be to let init_toast_snapshot itself
do that, but that seems like a bit of a layering violation; plus
I'm not quite convinced that's the only place with the issue.
(However, it *is* the only caller of GetOldestSnapshot() AFAICS.
So maybe everyplace else is calling GetTransactionSnapshot() to
begin with, in which case this could do likewise I should think.)

It really seems to me like _SPI_commit() should have started a
new transaction --- why is it okay to delay that?

BTW, why is this not caught by the plpgsql-toast.spec isolation test?
Seems like that's doing almost exactly the same thing as the trouble
reports.

			regards, tom lane

[1] https://www.postgresql.org/message-id/dae29212-ad31-8701-ef16-dd7420bf=
aa56%40perfexpert.ch