Thread: free(3)-ing variables in pg_dump
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. I'm trying to implement functionallity to dump multiple tables with multiple "-t <table-name>" options. 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? - -- 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/cE2SUopImDh2gfQRAhOxAJ0Wr7s98ufN4BEckpVem/tFfekIwQCghS+3 8x/TV1Oqx++ywYDyOJxQSCU= =uKgq -----END PGP SIGNATURE-----
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