]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix edge case in plpgsql's make_callstmt_target().
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 7 Aug 2024 16:54:39 +0000 (12:54 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 7 Aug 2024 16:54:39 +0000 (12:54 -0400)
commit7f875fb5bd603d8640cc7aca2c79c604aacd3890
treebd62ff83c38172ff63f14245fc4ff043adf76c32
parent7696b2ea52416cc2f4046a359d3b6f760e4c013d
Fix edge case in plpgsql's make_callstmt_target().

If the plancache entry for the CALL statement is already stale,
it's possible for us to fetch an old procedure OID out of it,
and then fail with "cache lookup failed for function NNN".
In ordinary usage this never happens because make_callstmt_target
is called just once immediately after building the plancache
entry.  It can be forced however by setting up an erroneous CALL
(that causes make_callstmt_target itself to report an error),
then dropping/recreating the target procedure, then repeating
the erroneous CALL.

To fix, use SPI_plan_get_cached_plan() to fetch the plancache's
plan, rather than assuming we can use SPI_plan_get_plan_sources().
This shouldn't add any noticeable overhead in the normal case,
and in the stale-plan case we'd have had to replan anyway a little
further down.

The other callers of SPI_plan_get_plan_sources() seem OK, because
either they don't need up-to-date plans or they know that the
query was just (re) planned.  But add some commentary in hopes
of not falling into this trap again.

Per bug #18574 from Song Hongyu.  Back-patch to v14 where this coding
was introduced.  (Older branches have comparable code, but it's run
after any required replanning, so there's no issue.)

Discussion: https://postgr.es/m/18574-2ce7ba3249221389@postgresql.org
src/backend/executor/spi.c
src/pl/plpgsql/src/pl_exec.c