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.
