pgsql: Fix re-execution of a failed SQLFunctionCache entry.
От | Tom Lane |
---|---|
Тема | pgsql: Fix re-execution of a failed SQLFunctionCache entry. |
Дата | |
Msg-id | E1uop7i-000rZj-12@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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(-)
В списке pgsql-committers по дате отправления: