* Tom Lane wrote:
> Karsten Desler <[EMAIL PROTECTED]> writes:
> > * Bruce Momjian wrote:
> >> I think what you are seeing is that the getaddrinfo memory is placed in
> >> the PGconn structure that isn't freed until PQclear is called. Does
> >> your test call PQclear()?
>
> > s/PQclear/PQfinish/
> > It does call PQclear on the result, and PQfinish on the connection.
>
> In that case I think there is no doubt that you've found a bug in
> getaddrinfo/freeaddrinfo, and you ought to be reporting it to your
> libc provider. We do call freeaddrinfo on the result of getaddrinfo,
> so if not everything is cleaned up, that's a library bug not ours.
>
> You could check this by reducing the test case to getaddrinfo()
> then freeaddrinfo() using the same parameters that fe-connect.c
> passes.
Indeed. Sorry for the noise.
The GNU libc 2.3.2 leaks ai->ai_canonname for every struct addrinfo
in the result list.
The original problem hasn't happened again (it seems like the faulty
ethernet switch, that was the cause for the flaky connection was
finally replaced). Anyway, if it happenes again, I'll notify you.
Regards,
Karsten Desler
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
