Thread: free(3)-ing variables in pg_dump

free(3)-ing variables in pg_dump

From
Andreas Joseph Krogh
Date:
-----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-----


Re: free(3)-ing variables in pg_dump

From
Andrew Dunstan
Date:
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



Re: free(3)-ing variables in pg_dump

From
Andreas Joseph Krogh
Date:
-----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-----


Re: free(3)-ing variables in pg_dump

From
Tom Lane
Date:
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