BUG #19073: there are meaningless code in _SPI_execute_plan() when canSetTag is true
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t73333psql -h localhost -U postgresBuilt from patchset v2 (message #2), September 20, 2026 at 09:32 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t73333_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t73333_2 && git checkout t73333_2Patchset v2 (message #2) is on t73333_2
The following bug has been logged on the website:
Bug reference: 19073
Logged by: Webbo Han
Email address: webbohan@qq.com
PostgreSQL version: 18.0
Operating system: all
Description:
In function _SPI_execute_plan(), `my_tuptable` is local variable and
initialized as NULL.
If plan is canSetTag subqueries, `SPI_freetuptable(my_tuptable)` is
meaningless, because `my_tuptable` is NULL.
We'd better remove this code.
there is patch.
I have remove the meaningless code.
------------------ 原始邮件 ------------------
发件人: "webbohan" <noreply@postgresql.org>;
发送时间: 2025年10月5日(星期天) 上午10:29
收件人: "pgsql-bugs"<pgsql-bugs@lists.postgresql.org>;
抄送: "webbohan"<webbohan@qq.com>;
主题: BUG #19073: there are meaningless code in _SPI_execute_plan() when canSetTag is true
The following bug has been logged on the website:
Bug reference: 19073
Logged by: Webbo Han
Email address: webbohan@qq.com
PostgreSQL version: 18.0
Operating system: all
Description:
In function _SPI_execute_plan(), `my_tuptable` is local variable and
initialized as NULL.
If plan is canSetTag subqueries, `SPI_freetuptable(my_tuptable)` is
meaningless, because `my_tuptable` is NULL.
We'd better remove this code.
On Sat, Oct 4, 2025, at 11:29 PM, PG Bug reporting form wrote:
In function _SPI_execute_plan(), `my_tuptable` is local variable and
initialized as NULL.
If plan is canSetTag subqueries, `SPI_freetuptable(my_tuptable)` is
meaningless, because `my_tuptable` is NULL.
We'd better remove this code.
There could be multiple statements. The first case will call SPI_freetuptable()
and it is a noop. The code path you are referring to is inside a foreach loop
and a previous statement might set my_tuptable and needs to be freed before
reusing it. That's exactly what the comment says.
/*
* The last canSetTag query sets the status values returned to the
* caller. Be careful to free any tuptables not returned, to
* avoid intra-transaction memory leak.
*/
if (canSetTag)
{
my_processed = _SPI_current->processed;
SPI_freetuptable(my_tuptable);
my_tuptable = _SPI_current->tuptable;
my_res = res;
}
--
Euler Taveira
EDB https://www.enterprisedb.com/
"Euler Taveira" <euler@eulerto.com> writes:
On Sat, Oct 4, 2025, at 11:29 PM, PG Bug reporting form wrote:
If plan is canSetTag subqueries, `SPI_freetuptable(my_tuptable)` is
meaningless, because `my_tuptable` is NULL.
There could be multiple statements. The first case will call SPI_freetuptable()
and it is a noop. The code path you are referring to is inside a foreach loop
and a previous statement might set my_tuptable and needs to be freed before
reusing it. That's exactly what the comment says.
Yeah. You'd only reach this case if there were multiple SQL
statements in the string given to SPI_execute() or similar,
but that's perfectly legal.
regards, tom lane