aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistbuildbuffers.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-10-12 13:31:24 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-10-12 13:31:24 -0400
commitf35c117700122cca2229b9a20a30d12a2ace7bfd (patch)
treefcf0d4b4a165efe2136fbb01145834f1bf804fa4 /src/backend/access/gist/gistbuildbuffers.c
parent8b231d9753287fc16328af2ab31943b79e1cc8a3 (diff)
downloadpostgresql-f35c117700122cca2229b9a20a30d12a2ace7bfd.tar.gz
postgresql-f35c117700122cca2229b9a20a30d12a2ace7bfd.zip
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
Diffstat (limited to 'src/backend/access/gist/gistbuildbuffers.c')
0 files changed, 0 insertions, 0 deletions