Re: free C string
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:t44556psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 27, 2026 at 04:36 PM.
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 t44556_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 t44556_2 && git checkout t44556_2Patchset v2 (message #2) is on t44556_2
Zhihong Yu <zyu@yugabyte.com> writes:
I was looking at fmgr_internal_validator().
It seems prosrc is only used internally.
The patch frees the C string prosrc points to, prior to returning.
There's really very little point in adding such code. Our memory
context mechanisms take care of minor leaks like this, with less
code and fewer cycles expended than explicit pfree calls require.
It's worth trying to clean up explicitly in code that might get
executed many times in a row, or might be allocating very big
temporary chunks; but fmgr_internal_validator hardly falls in
that category.
regards, tom lane
Import Notes
Reply to msg id not found: CALNJ-vRiyD9e9Md+UjnBkGj1ShHy5X3UzyLXECr37YHEeDjkDg@mail.gmail.comReference msg id not found: CALNJ-vRiyD9e9Md+UjnBkGj1ShHy5X3UzyLXECr37YHEeDjkDg@mail.gmail.com
On Wed, Jul 14, 2021 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zhihong Yu <zyu@yugabyte.com> writes:
I was looking at fmgr_internal_validator().
It seems prosrc is only used internally.
The patch frees the C string prosrc points to, prior to returning.There's really very little point in adding such code. Our memory
context mechanisms take care of minor leaks like this, with less
code and fewer cycles expended than explicit pfree calls require.
It's worth trying to clean up explicitly in code that might get
executed many times in a row, or might be allocating very big
temporary chunks; but fmgr_internal_validator hardly falls in
that category.regards, tom lane
Hi,
How about this occurrence which is in a loop ?
Thanks
Zhihong Yu <zyu@yugabyte.com> writes:
On Wed, Jul 14, 2021 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
There's really very little point in adding such code. Our memory
context mechanisms take care of minor leaks like this, with less
code and fewer cycles expended than explicit pfree calls require.
It's worth trying to clean up explicitly in code that might get
executed many times in a row, or might be allocating very big
temporary chunks; but fmgr_internal_validator hardly falls in
that category.
How about this occurrence which is in a loop ?
I'd say the burden is on you to prove that it's worth worrying
about, not vice versa. If we added pfree everywhere we possibly
could, the code would be larger and slower, not faster.
regards, tom lane