Em qui., 27 de ago. de 2020 às 12:46, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes: > Is this something to worry about, or is it another problem with the > analysis tool, that nobody cares about?
As far as the first one goes, I'd bet on buggy analysis tool. The complained-of allocation is evidently for the "extra" state associated with the timezone GUC variable, and AFAICS guc.c is quite careful not to leak those. It is true that the block will still be allocated at process exit, but that doesn't make it a leak.
I did not trace the second one in any detail, but I don't believe guc.c leaks sourcefile strings either. There's only one place where it overwrites them, and that place frees the old value.
If these allocations do genuinely get leaked in some code path, this report is of exactly zero help in finding where; and I'm afraid I'm not very motivated to go looking for a bug that probably doesn't exist.
Hi Tom,
thanks for taking a look at this.
I tried to find where the zone table is freed, without success.
It would be a big surprise for me, if this tool is buggy.
Anyway, it's just a sample of the total report, which is 10 mb (postmaster.log), done with the regression tests.
