pgsql: Fix edge case in plpgsql's make_callstmt_target().

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix edge case in plpgsql's make_callstmt_target().
Date: 2024-08-07 16:55:07
Message-ID: E1sbjwJ-0039NM-7E@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a073835c19cfcd5ce1c9826f2f9356944d807b0e

Modified Files
--------------
src/backend/executor/spi.c | 2 ++
src/pl/plpgsql/src/pl_exec.c | 26 ++++++++++++++------------
2 files changed, 16 insertions(+), 12 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2024-08-07 17:08:35 Re: pgsql: Introduce hash_search_with_hash_value() function
Previous Message Robert Haas 2024-08-07 16:30:18 Re: pgsql: Introduce hash_search_with_hash_value() function