psql memory leaks
psql memory leaks
От:
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Дата:
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
Re: psql memory leaks
От:
Corey Huinker <corey.huinker@gmail.com>
Дата:
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.
Re: psql memory leaks
От:
Michael Paquier <michael@paquier.xyz>
Дата:
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