| From: | Antonio Vieiro <antonio(at)antonioshome(dot)net> |
|---|---|
| To: | pgsql <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Memory leak somewhere at PQconnectdb? |
| Date: | 2011-09-02 10:49:10 |
| Message-ID: | CAPHN3JVY8hR--7voyXFyJGVcim6iTkq8znxZC92gtViP4OZ8ZQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi all,
I now know it's somewhat an "academic exercise" of little practical
importance, thanks for the clarification!!
Cheers,
Antonio
2011/9/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> writes:
>> Even better, add a valgrind suppressions file for the warnings and
>> ignore them. They are "leaks" only in the sense that a static variable
>> is a leak, ie not at all.
>
> Yeah, the bottom line here is that valgrind will warn about many things
> that are not genuine problems. You need to learn how to judge the tool's
> reports. A single allocation that is still reachable at program exit is
> almost never a real problem. If it's unreachable, or there's a lot of
> instances, it may be worth worrying about.
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Johnston | 2011-09-02 13:16:06 | Re: UPDATE using query; per-row function calling problem |
| Previous Message | gbrun | 2011-09-02 10:48:16 | Re: Missing DLL after unplaned server stop |