]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Avoid detoasting failure after COMMIT inside a plpgsql FOR loop.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 20 May 2021 22:32:37 +0000 (18:32 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 20 May 2021 22:32:37 +0000 (18:32 -0400)
commitf21fadafaf0fb5ea4c9622d915972651273d62ce
tree3ebcc8a234a9dbe43b2ddb8184d4b486c19da700
parent4f586fe244a296d7c781de3f06c54755f2ae222b
Avoid detoasting failure after COMMIT inside a plpgsql FOR loop.

exec_for_query() normally tries to prefetch a few rows at a time
from the query being iterated over, so as to reduce executor
entry/exit overhead.  Unfortunately this is unsafe if we have
COMMIT or ROLLBACK within the loop, because there might be
TOAST references in the data that we prefetched but haven't
yet examined.  Immediately after the COMMIT/ROLLBACK, we have
no snapshots in the session, meaning that VACUUM is at liberty
to remove recently-deleted TOAST rows.

This was originally reported as a case triggering the "no known
snapshots" error in init_toast_snapshot(), but even if you miss
hitting that, you can get "missing toast chunk", as illustrated
by the added isolation test case.

To fix, just disable prefetching in non-atomic contexts.  Maybe
there will be performance complaints prompting us to work harder
later, but it's not clear at the moment that this really costs
much, and I doubt we'd want to back-patch any complicated fix.

In passing, adjust that error message in init_toast_snapshot()
to be a little clearer about the likely cause of the problem.

Patch by me, based on earlier investigation by Konstantin Knizhnik.

Per bug #15990 from Andreas Wicht.  Back-patch to v11 where
intra-procedure COMMIT was added.

Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org
src/backend/access/common/toast_internals.c
src/pl/plpgsql/src/pl_exec.c
src/test/isolation/expected/plpgsql-toast.out
src/test/isolation/specs/plpgsql-toast.spec