Re: Re all: Report some potential memory leak bugs in pg_dump.c

Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> Here the amount of leaked memory is likely to be very small (I never heard of
> people having thousands of text search templates or parsers), and pg_dump isn't
> a long lived process so probably no one thought it was worth to extra code to
> free that memory, which I agree with.

Yeah. For context,

$ valgrind pg_dump regression >/dev/null

reports

==59330== HEAP SUMMARY:
==59330== in use at exit: 3,909,248 bytes in 70,831 blocks
==59330== total heap usage: 546,364 allocs, 475,533 frees, 34,377,280 bytes allocated
==59330==
==59330== LEAK SUMMARY:
==59330== definitely lost: 6 bytes in 6 blocks
==59330== indirectly lost: 0 bytes in 0 blocks
==59330== possibly lost: 0 bytes in 0 blocks
==59330== still reachable: 3,909,242 bytes in 70,825 blocks
==59330== suppressed: 0 bytes in 0 blocks

So as long as you're willing to take the regression database as
typical, pg_dump does not have any interesting leak problem.

There are certainly things that this simple test doesn't reach
--- publications/subscriptions are another area besides custom
text search configurations --- but it seems unlikely that a
database would have enough of any of those to justify much worry
about whether those code paths leak anything.

regards, tom lane