| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Schreiber <daniel(dot)schreiber(at)hrz(dot)tu-chemnitz(dot)de> |
| Subject: | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times |
| Date: | 2026-04-22 22:10:07 |
| Message-ID: | CAOYmi+nJ19kj4bnyyX66VpvTPhjaGVWGvPsyVQdnV=R6aLGo0A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Apr 22, 2026 at 12:22 PM Nico Williams <nico(at)cryptonector(dot)com> wrote:
> Leaking a dl handle is a way to prevent unloading. Not saying that's a
> great answer, just that it's a workaround.
Hmm, I did that for our handle to libpq-oauth, but I imagine that
leaking a handle to _ourselves_ may make someone very unhappy with us
at some point? Plus, it might kick off the tiniest, most pointless
arms race:
// why does libpq do this
dlclose(libpq_handle);
dlclose(libpq_handle);
I guess we could play around with RTLD_NODELETE... Something to keep
in the back pocket, maybe?
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2026-04-22 22:10:31 | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times |
| Previous Message | Tom Lane | 2026-04-22 19:23:53 | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2026-04-22 22:10:31 | Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed multiple times |
| Previous Message | Tom Lane | 2026-04-22 21:47:42 | Re: [RFC][PATCH] Order qual clauses by combined cost and selectivity |