psql memory leaks
I noticed that \bind is leaking memory for each option.
=# SELECT $1, $2, $3 \ bind 1 2 3 \g
The leaked memory blocks are comming from
psql_scan_slash_option(). The attached small patch resolves that
issue. I looked through the function's call sites, but I didn't find
the same mistake.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
0001-Fix-memory-leak-of-psql-s-bind.patchtext/x-patch; charset=us-asciiDownload+1-2
On Mon, Feb 20, 2023 at 9:56 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com>
wrote:
I noticed that \bind is leaking memory for each option.
=# SELECT $1, $2, $3 \ bind 1 2 3 \g
The leaked memory blocks are comming from
psql_scan_slash_option(). The attached small patch resolves that
issue. I looked through the function's call sites, but I didn't find
the same mistake.regards.
Good catch. Patch passes make check-world.
On Tue, Feb 21, 2023 at 02:03:43PM -0500, Corey Huinker wrote:
Good catch. Patch passes make check-world.
Indeed. I was reviewing the whole and there could be a point in
resetting bind_nparams at the end of SendQuery() to keep a correct
track of what's saved in the pset data for the bind parameters, but
not doing so is not a big deal either because we'd just reset it once
the full allocation of the parameters is done and bind_flag is all
about that. The code paths leading to the free seem correct, seen
from here.
--
Michael