PG Bug reporting form <noreply@postgresql.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
