Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times
| От | Nico Williams |
|---|---|
| Тема | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times |
| Дата | |
| Msg-id | aekf4cx42tNs6C0j@ubby обсуждение |
| Ответ на | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times
|
| Список | pgsql-hackers |
On Wed, Apr 22, 2026 at 11:29:04AM -0700, Jacob Champion wrote: > > (I'd be surprised if this were the only such resource leak across all > > supported versions and combinations of Kerberos, OpenSSL, OpenLDAP, > > Curl, etc. etc. From a quick search, you're the first to report this > > in the ten years since the leak was introduced, so there may be more > > dragons where you're headed.) > > If anyone has thoughts on that, I'd love to hear them. I don't mind > removing this unnecessary code in HEAD, or even backpatching as a > courtesy -- but if it were up to me, I would not guarantee zero global > resource leaks across libpq and its entire dependency graph. (Even if > we magically had control over all those dependencies, I think it'd > still be reasonable for libpq devs to use "allocate once and move on" > patterns... and I want to continue using those in my new code.) Leaking a dl handle is a way to prevent unloading. Not saying that's a great answer, just that it's a workaround.
В списке pgsql-hackers по дате отправления: