Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, a.wicht@gmail.com, pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2021-05-12T16:13:54Z
Lists: pgsql-bugs 
Hi,

On 2021-05-12 12:00:10 -0400, Tom Lane wrote:
> Yeah, on further thought, the real question to be asking here is
> "what's protecting that in-flight datum from becoming a dangling
> pointer?".  AFAICT, the answer right now is "nothing".  Therefore,
> it is *never* okay for plpgsql to be executing without a registered
> transaction snapshot; and it seems quite unlikely that it'd be any
> safer for any other PL.

A bit independently of this concrete issue, I wonder if we could make it
easier to detect such bugs. If we somehow™ associated an xmin horizon
with toasted datums, we could then assert before dereferencing that we
still guarantee that such a reference is still valid. The "somehow" part
obviously isn't entirely trivial, but it seems we could hack it by
encoding it as a different vartag?

Greetings,

Andres Freund

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.