From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | hghwng(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16348: Memory leak when parsing config |
Date: | 2020-04-07 15:22:28 |
Message-ID: | 29582.1586272948@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> ANALYSIS:
> When parsing config file, gui-file.l:ProcessConfig sets up memory context.
> It invokes guc-file.l:ProcessConfigFileInternal, which is expected to leak
> memory. It's okay because the leaked memory will be freed when cleaning up
> the context. Next, guc-file.l:ProcessConfigFileInternal associates each
> config item with filename by calling guc.c:set_config_option, which calls
> guc.c:guc_strdup. However, guc.c:guc_strdup is not aware of the memory
> context, and invokes libc.so:strdup directly.
And?
The places that use guc_strdup are expecting that the values will be
tracked and then freed when discarded. Perhaps there is a code path
where that's not happening, but you haven't either shown it or given
any reason to believe one exists.
As a quick cross-check, I set up a shell loop to send a constant stream
of SIGHUPs to an idle backend. I don't see any change in the backend's
memory consumption in "top". Maybe this test case is missing some
necessary factor ... but, again, you haven't given a reason to believe
there is one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-04-07 16:49:27 | Re: Don't try fetching future segment of a TLI. |
Previous Message | Jehan-Guillaume de Rorthais | 2020-04-07 15:17:36 | Re: [BUG] non archived WAL removed during production crash recovery |