Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries

Tom Lane <tgl@sss.pgh.pa.us>

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>
Date: 2021-05-11T23:01:34Z
Lists: pgsql-bugs
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-dd7420bfaa56%40perfexpert.ch



Commits

  1. Remove plpgsql's special-case code paths for SET/RESET.

  2. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.

  3. Avoid detoasting failure after COMMIT inside a plpgsql FOR loop.