Fix memory leak when guc.c decides a setting can't be applied now.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 12 Oct 2020 17:31:24 +0000 (13:31 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 12 Oct 2020 17:31:24 +0000 (13:31 -0400)
commit397ea901e85b83e6381a0edeba7a45d794063569
treed80ed5219b2cf66c9aa013f31a8905d5130388d1
parentfcd11329db5bca9993207f099a642a7d1cd59ff8
Fix memory leak when guc.c decides a setting can't be applied now.

The prohibitValueChange code paths in set_config_option(), which
are executed whenever we re-read a PGC_POSTMASTER variable from
postgresql.conf, neglected to free anything before exiting.  Thus
we'd leak the proposed new value of a PGC_STRING variable, as noted
by BoChen in bug #16666.  For all variable types, if the check hook
creates an "extra" chunk, we'd also leak that.

These are malloc not palloc chunks, so there is no mechanism for
recovering the leaks before process exit.  Fortunately, the values
are typically not very large, meaning you'd have to go through an
awful lot of SIGHUP configuration-reload cycles to make the leakage
amount to anything.  Still, for a long-lived postmaster process it
could potentially be a problem.

Oversight in commit 2594cf0e8.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/16666-2c41a4eec61b03e1@postgresql.org
src/backend/utils/misc/guc.c