free(3)-ing variables in pg_dump

Andreas Joseph Krogh wrote:

Hi.

I'm trying to implement functionallity to dump multiple tables with multiple
"-t <table-name>" options.

excellent.

While digging in the source for pg_dump I see that
many local static variables are not freed( with free(3)). Is this lazy
programming because pg_dump is its own process where the kernel takes care
of cleaning up, so you don't bother to do it for some of the variables? I'm
malloc'ing some structs to build a list over tables which are marked for
dumping. Shall I bother to free(3) them?

I don't think it's lazy, probably just a product of the programmer's
awareness that little would be gained by it. Relying on the OS to clean
up for you is perfectly valid in a shortlived program unless you get a
major problem with memory leaks.

"If it ain't broke, don't fix it" would be my take.

(If this is not the consensus I'm going to have some more work to do in
the C port of initdb I'm working on, which is about one third done :-)

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 September 2003 16:25, Andrew Dunstan wrote:

Andreas Joseph Krogh wrote:

Hi.

I'm trying to implement functionallity to dump multiple tables with
multiple "-t <table-name>" options.

excellent.

While digging in the source for pg_dump I see that
many local static variables are not freed( with free(3)). Is this lazy
programming because pg_dump is its own process where the kernel takes
care of cleaning up, so you don't bother to do it for some of the
variables? I'm malloc'ing some structs to build a list over tables which
are marked for dumping. Shall I bother to free(3) them?

I don't think it's lazy, probably just a product of the programmer's
awareness that little would be gained by it. Relying on the OS to clean
up for you is perfectly valid in a shortlived program unless you get a
major problem with memory leaks.

I didn't mean lazy as in bad - I ment lazy as in just what you pointed out:
little would be gained by it, so why bother.

"If it ain't broke, don't fix it" would be my take.

(If this is not the consensus I'm going to have some more work to do in
the C port of initdb I'm working on, which is about one third done :-)

:-)

- --
Andreas Joseph Krogh <andreak@officenet.no>
Managing Director, Senior Software Developer
OfficeNet AS

- - Writing software is more fun than working.

gpg public_key: http://dev.officenet.no/~andreak/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/cF3DUopImDh2gfQRAtR4AJ499CK4QcGO9Dc0Wato46/wZMxZ/wCaApSP
463Z/DfsEBtUvQ50h/osKAc=
=eEqD
-----END PGP SIGNATURE-----

Andreas Joseph Krogh <andreak@officenet.no> writes:

Shall I bother to free(3) them?

No. They need to live for the entire pg_dump run, so there's no point
in writing code to free them.

regards, tom lane