pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix re-execution of a failed SQLFunctionCache entry. 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix re-execution of a failed SQLFunctionCache entry. @ 2025-08-20 20:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2025-08-20 20:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix re-execution of a failed SQLFunctionCache entry. If we error out during execution of a SQL-language function, we will often leave behind non-null pointers in its SQLFunctionCache's cplan and eslist fields. This is problematic if the SQLFunctionCache is re-used, because those pointers will point at resources that were released during error cleanup. This problem escaped detection so far because ordinarily we won't re-use an FmgrInfo+SQLFunctionCache struct after a query error. However, in the rather improbable case that someone implements an opclass support function in SQL language, there will be long-lived FmgrInfos for it in the relcache, and then the problem is reachable after the function throws an error. To fix, add a flag to SQLFunctionCache that tracks whether execution escapes out of fmgr_sql, and clear out the relevant fields during init_sql_fcache if so. (This is going to need more thought if we ever try to share FMgrInfos across threads; but it's very far from being the only problem such a project will encounter, since many functions regard fn_extra as being query-local state.) This broke at commit 0313c5dc6; before that we did not try to re-use SQLFunctionCache state across calls. Hence, back-patch to v18. Bug: #19026 Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19026-90aed5e71d0c8af3@postgresql.org Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a67d4847a4319ddee8a8ee7d8945c07301ada66e Modified Files -------------- src/backend/executor/functions.c | 29 +++++++++++++++++++++++ src/test/regress/expected/create_function_sql.out | 21 +++++++++++++++- src/test/regress/sql/create_function_sql.sql | 17 +++++++++++++ 3 files changed, 66 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix re-execution of a failed SQLFunctionCache entry. @ 2025-08-20 20:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2025-08-20 20:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix re-execution of a failed SQLFunctionCache entry. If we error out during execution of a SQL-language function, we will often leave behind non-null pointers in its SQLFunctionCache's cplan and eslist fields. This is problematic if the SQLFunctionCache is re-used, because those pointers will point at resources that were released during error cleanup. This problem escaped detection so far because ordinarily we won't re-use an FmgrInfo+SQLFunctionCache struct after a query error. However, in the rather improbable case that someone implements an opclass support function in SQL language, there will be long-lived FmgrInfos for it in the relcache, and then the problem is reachable after the function throws an error. To fix, add a flag to SQLFunctionCache that tracks whether execution escapes out of fmgr_sql, and clear out the relevant fields during init_sql_fcache if so. (This is going to need more thought if we ever try to share FMgrInfos across threads; but it's very far from being the only problem such a project will encounter, since many functions regard fn_extra as being query-local state.) This broke at commit 0313c5dc6; before that we did not try to re-use SQLFunctionCache state across calls. Hence, back-patch to v18. Bug: #19026 Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19026-90aed5e71d0c8af3@postgresql.org Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/906b68217a1e756a49acd0864773680d1eb8a10d Modified Files -------------- src/backend/executor/functions.c | 29 +++++++++++++++++++++++ src/test/regress/expected/create_function_sql.out | 21 +++++++++++++++- src/test/regress/sql/create_function_sql.sql | 17 +++++++++++++ 3 files changed, 66 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-08-20 20:09 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-08-20 20:09 pgsql: Fix re-execution of a failed SQLFunctionCache entry. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-20 20:09 pgsql: Fix re-execution of a failed SQLFunctionCache entry. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox