Re: [PATCH] Fix memory leak in pg_config

Hi Ivan,

> LeakSanitizer reports 2829 bytes leaked in 47 allocations.

I can confirm the leak and the fix. The 47 allocations are exactly 23
names + 23 settings + 1 array. With your patch the tool reports zero.

Fun archaeology: this leak celebrates its 10th anniversary this year.
It arrived with a5c43b88694 (PG 9.6), which introduced get_configdata()
with the comment "the caller is responsible for pfreeing the result".
pg_config has been ignoring that contract ever since. Before 9.6 it
used static buffers and had nothing to leak at all. Simpler times.

One thing to be aware of: our CI runs sanitizers with
detect_leaks=0, and the comment there says "too many uninteresting
leak errors in short-lived binaries". This leak is a prime specimen
of the genre, so the answer here may well be "the OS frees it faster
than we do". If the goal is quiet LSan runs, a suppression list might
scale better: there are many binaries other than pg_config that leak
too. Anyway, I think it would be good to quite LSan if possible...

Two small notes:

- Validating the arguments before calling get_configdata() would
leave a single free before return instead of three call sites.
- The function definition puts "static" alone on its own line. The
usual style is "static void" together, then the function name on
the next line.

Thank you!

Best regards, Andrey Borodin.