Fix memory leak in tzparser.c
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:t52903psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 02:08 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 t52903_1 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 t52903_1 && git checkout t52903_1Patchset v1 (message #1) is on t52903_1
Hi hackers,
I noticed a memory leak in the addToArray() function in src/backend/utils/misc/tzparser.c.
When the override parameter is true and a duplicate timezone abbreviation is found,
the code overwrites midptr->zone without freeing the previously allocated memory.
The fix would be:
- midptr->zone = entry->zone;
+ if (midptr->zone != NULL)
+ pfree(midptr->zone);
+ midptr->zone = entry->zone;While the memory is managed by a temp memory context that gets cleaned up
eventually, the coarse-grained management might cause some memory to
accumulate during ParseTzFile() recursive calls when processing @INCLUDE
directives.
I've attached a patch with this change in case anyone thinks it's worth
applying.
Regards,
Shixin Wang
On Tue, Dec 16, 2025 at 05:55:32AM +0000, Shixin Wang wrote:
While the memory is managed by a temp memory context that gets cleaned up
eventually, the coarse-grained management might cause some memory to
accumulate during ParseTzFile() recursive calls when processing @INCLUDE
directives.I've attached a patch with this change in case anyone thinks it's worth
applying.
Why does it matter? load_tzoffsets() is the sole caller of
ParseTzFile() and it uses a temporary memory context named
TZParserMemory to not have to do cleanups like the one you are
proposing here.
--
Michael
On Tue, Dec 16, 2025 at 1:29 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Dec 16, 2025 at 05:55:32AM +0000, Shixin Wang wrote:
While the memory is managed by a temp memory context that gets cleaned up
eventually, the coarse-grained management might cause some memory to
accumulate during ParseTzFile() recursive calls when processing @INCLUDE
directives.I've attached a patch with this change in case anyone thinks it's worth
applying.Why does it matter? load_tzoffsets() is the sole caller of
ParseTzFile() and it uses a temporary memory context named
TZParserMemory to not have to do cleanups like the one you are
proposing here.
+1. But maybe Shixin has seen a scenario where this temporary
accumulation has caused some problems because say there were many
entries whose zone was replaced? Shixin, what problem did you see
which prompted you to create this patch?
--
Best Wishes,
Ashutosh Bapat
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
On Tue, Dec 16, 2025 at 1:29 PM Michael Paquier <michael@paquier.xyz> wrote:
Why does it matter? load_tzoffsets() is the sole caller of
ParseTzFile() and it uses a temporary memory context named
TZParserMemory to not have to do cleanups like the one you are
proposing here.
+1. But maybe Shixin has seen a scenario where this temporary
accumulation has caused some problems because say there were many
entries whose zone was replaced? Shixin, what problem did you see
which prompted you to create this patch?
There are only several hundred timezone names in the entire world,
so it's really difficult to believe any interesting amount of
transient memory consumption here.
regards, tom lane