>>>>> "PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> When an error occurs in `SELECT FOR UPDATE` using an index, release
PG> process of the index access method is not called.
That's true in general for all errors.
PG> At this time, the index access method ambeginscan() is called but
PG> since amendscan() is not called, ambeginscan() can not properly
PG> release the resource set in IndexScanDesc::opaque.
Any resources that you allocate for the index scan have to be such that
they get released automatically even on error paths: memory allocation
is handled by the memory context system, things like buffer pins are
handled by the ResourceOwner mechanism; locks are released by
(sub)transaction abort.
PG> Solution:
PG> For example, if an error occurs while calling PortalRun() in
PG> exec_simple_query() of src/backend/tcop/postgresq.c, amendscan()
PG> will not be called because PortalDrop() will not be called.
PG> Therefore, it is good to postpone even when an error occurs as
PG> follows.
Your solution is hopeless for many reasons, not least of which is the
fact that an error while running the portal will cause it to be marked
as failed, and executor shutdown will not be run for a failed portal.
--
Andrew (irc:RhodiumToad)