From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: wliang@stu.xidian.edu.cn, pgsql-bugs <pgsql-bugs@lists.postgresql.org>,
        david.g.johnston@gmail.com
Subject: Re: Re all: Report some potential memory leak bugs in pg_dump.c
In-reply-to: <20220219111005.57bfn4qshuqxzkzi@jrouhaud>
References: <1f102fb7.f70.17f1102ec92.Coremail.wliang@stu.xidian.edu.cn>
 <20220219111005.57bfn4qshuqxzkzi@jrouhaud>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Sat, 19 Feb 2022 19:10:05 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <59833.1645289388.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 19 Feb 2022 11:49:48 -0500
Message-ID: <59834.1645289388@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/59834.1645289388%40sss.pgh.pa.us>
Precedence: bulk

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

Yeah.  For context,

$ valgrind pg_dump regression >/dev/null

reports

=3D=3D59330=3D=3D HEAP SUMMARY:
=3D=3D59330=3D=3D     in use at exit: 3,909,248 bytes in 70,831 blocks
=3D=3D59330=3D=3D   total heap usage: 546,364 allocs, 475,533 frees, 34,37=
7,280 bytes allocated
=3D=3D59330=3D=3D =

=3D=3D59330=3D=3D LEAK SUMMARY:
=3D=3D59330=3D=3D    definitely lost: 6 bytes in 6 blocks
=3D=3D59330=3D=3D    indirectly lost: 0 bytes in 0 blocks
=3D=3D59330=3D=3D      possibly lost: 0 bytes in 0 blocks
=3D=3D59330=3D=3D    still reachable: 3,909,242 bytes in 70,825 blocks
=3D=3D59330=3D=3D         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