Re: Libpq question related to allocated resources

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Libpq question related to allocated resources
Date: 2022-06-28 03:22:37
Message-ID: 2246456.1656386557@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Karl Denninger <karl(at)denninger(dot)net> writes:
> But -- I still have a /lot /of memory out on the heap according to
> jemalloc stats that is not being deallocated, and what's worse is that
> if I rig the code to call PQfinish and then PQconnect once again I get
> /even more /imbalanced allocate/free counts (and the memory use in said
> buckets to go with them.)

Hmmm ... I'm not aware of any memory leaks in libpq, but that doesn't
mean there are none. Of course, if you're forgetting to PQclear()
some PGresults, that's not libpq's fault ;-).

> The obvious question, given the warnings in the FastCGI library: Does
> libpq /modify /the process environment?

No. At least, I see no setenv() calls in it, and I think that it'd
be pretty unfriendly for a library to do that to its host application.

> A quick grep implies that indeed it may in
> backend/libpq/auth.c at least,

backend/libpq is unrelated to interfaces/libpq. (I've seen hints
that they arose from a common code base, but if so, that was a
few decades and a lot of rewrites ago.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Amit Kapila 2022-06-28 03:26:39 Re: Support logical replication of DDLs
Previous Message David Rowley 2022-06-27 21:50:01 Re: Unique index prohibits partial aggregates