| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: plpython: share the SD dictionary across cache entries of a func |
| Date: | 2026-11-12 16:48:13 |
| Message-ID: | E1xRXy9-00000000SRd-0Eui@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
plpython: share the SD dictionary across cache entries of a function.
Since commit 9bcb8a694 moved PL/Python onto funccache.c, each cache
entry gets its own SD dictionary. funccache.c builds separate entries
for the same function when the input collation differs, when a trigger
function is used by several triggers, or when the argument or result
types differ (as in polymorphic functions, a case PL/Python doesn't
yet support). This results in an unintentional change of behavior
from previous releases, which intended to share an instance of SD
across all calls of a plain function, or all calls for a given trigger
rel for a trigger function. The documentation does not suggest that
the arguments (including collation) should have anything to do with it.
However, the previous implementation had its own problem: CREATE OR
REPLACE FUNCTION caused a new SD to be generated, which is not what
you'd expect after reading the admittedly-terse documentation.
That appears to be an implementation artifact not an intentional
behavioral choice.
To fix, keep long-lived references to the SD dictionaries in a
separate hash table, keyed by function OID and (for triggers) the
relation OID, and then copy a reference into each function cache
entry. This makes SD semantics independent of what funccache.c does,
which seems like a good future-proofing choice. A function's SD will
now survive CREATE OR REPLACE FUNCTION, since that doesn't change
the function's OID.
As before, an inline DO block has its own one-use SD dictionary.
Bug: #19816
Reported-by: Marcos Castedo <marcos(dot)castedo(at)anachronics(dot)com>
Author: shihao zhong <zhong950419(at)gmail(dot)com>
Reviewed-by: Marcos Castedo <marcos(dot)castedo(at)anachronics(dot)com>
Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion: https://postgr.es/m/19816-921b5cbc3ee63146@postgresql.org
Backpatch-through: 19
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/c13c414c6e018fcbd9fa6e36e778a852c76a1562
Modified Files
--------------
src/pl/plpython/expected/plpython_global.out | 24 +++++++++
src/pl/plpython/plpy_main.c | 5 ++
src/pl/plpython/plpy_procedure.c | 80 +++++++++++++++++++++++++---
src/pl/plpython/sql/plpython_global.sql | 18 +++++++
src/tools/pgindent/typedefs.list | 2 +
5 files changed, 123 insertions(+), 6 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-11-12 17:18:36 | pgsql: Make float8_regr_combine() handle edge cases like float8_regr_ac |
| Previous Message | Tomas Vondra | 2026-11-12 16:33:19 | Re: pgsql: Handle numeric overflow in numeric_minmax_multi_ops |