Re: Detecting memory leaks with libpq? - Mailing list pgsql-general

From Antonio Vieiro
Subject Re: Detecting memory leaks with libpq?
Date
Msg-id CAPHN3JV+eOub0VVOC0KM-Hv6nGBq6SW-FP8bimzGho=5mXWt6Q@mail.gmail.com
Whole thread Raw
In response to Re: Detecting memory leaks with libpq?  (Ben Chobot <bench@silentmedia.com>)
List pgsql-general
Hi all,

Well, thanks for the ideas. I also prefer cleaning things up myself
before exiting.

I was expecting some small statistics from the library (connections
opened/closed, PGresults returned/freed, etc.) but I can do it myself,
before trying out  more heavyweight tools such as valgrind.

Cheers,
Antonio

2011/7/19 Ben Chobot <bench@silentmedia.com>:
> On Jul 19, 2011, at 6:28 AM, Craig Ringer wrote:
>
>> Note that some "leaks" that are reported are _normal_ in most software. There is absolutely no harm in not free()ing
astructure that's allocated only once during init and never messed with afterwards. The OS clears the memory anyway, so
free()ingit is just a waste of CPU cycles. 
>
> Getting off topic here but "normal" isn't always "desirable." Some might say that allocating singletons and never
freeingthem - even after they're no longer valid - is just sloppy code. By the same logic, dangling pointers are A-OK,
solong as you never use them. So yes, it might be an extra cycle or two to free it now, but that's a cycle or two the
OSwon't have to do later, and it's almost certainly better to have a cleaner codebase that's 0.000001% slower. 
>
> Or so some might argue. :)

pgsql-general by date:

Previous
From: Steve Crawford
Date:
Subject: Re: timezone help?
Next
From: Chris Travers
Date:
Subject: Question on utility statements and parameterization