MIME-Version: 1.0
References: <f7fe39b3-7e99-4939-8852-07350549161d@hrz.tu-chemnitz.de> <CAOYmi+=e9bQQa1jgLqZ18m5w-7KA44VeL9FON6i2gd8bi=d5Jw@mail.gmail.com>
In-Reply-To: <CAOYmi+=e9bQQa1jgLqZ18m5w-7KA44VeL9FON6i2gd8bi=d5Jw@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 22 Apr 2026 11:29:04 -0700
Message-ID: <CAOYmi+kac3wEE3iqxHfHCNd_n2i-Or=n+Qk8_G24UZn2uz3DyQ@mail.gmail.com>
Subject: Re: PostgreSQL 17: Bug in libpq when libpq is dlopened/closed
 multiple times
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Daniel Schreiber <daniel.schreiber@hrz.tu-chemnitz.de>
Content-Type: multipart/mixed; boundary="000000000000928dcd065010b544"
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2Bkac3wEE3iqxHfHCNd_n2i-Or%3Dn%2BQk8_G24UZn2uz3DyQ%40mail.gmail.com>
Precedence: bulk

--000000000000928dcd065010b544
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[moving to -hackers]

On Fri, Apr 17, 2026 at 12:14=E2=80=AFPM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Fri, Apr 17, 2026 at 7:33=E2=80=AFAM Daniel Schreiber
> <daniel.schreiber@hrz.tu-chemnitz.de> wrote:
> > my colleagues and I probably found a bug in libpq when libpq is dlopene=
d
> > and closed multiple times during the lifetime of a process. In our setu=
p
> > we use a PAM module which links to libpq. The process using PAM is
> > linked against openssl, so openssl is loaded during the complete
> > lifetime of the process whereas libpq is loaded only during PAM
> > authentication (and unloaded when PAM has finished).
> >
> > [snip]
> >
> > According to our findings every time a connection is established after
> > dlopening libpq one of the 127 available BIO_METHOD structures in
> > OpenSSL is consumed:
> > https://github.com/postgres/postgres/blob/REL_17_9/src/interfaces/libpq=
/fe-secure-openssl.c#L1987
>
> Right. I think in this *particular* case, we should simply skip the
> call to BIO_get_new_index(). We don't need it, IIUC.

Attached is a proposal to do that.

> But I think we may also need to set expectations on whether or not
> infinite dlopen/dlclose loops are supported in general. If we ever
> come across a situation in which a call to BIO_get_new_index() is
> necessary, that leak just fundamentally can't be plugged. The same is
> true for any third-party libraries (or their dependencies, or
> theirs...) that require "one-time", irreversible calls which can't be
> tracked after we're unloaded. And we can't push these concerns up to
> the top level application developer, because they don't know we exist.
>
> (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.)

Thanks,
--Jacob

--000000000000928dcd065010b544
Content-Type: application/octet-stream; 
	name="0001-Remove-call-to-BIO_get_new_index-in-OpenSSL-code.patch"
Content-Disposition: attachment; 
	filename="0001-Remove-call-to-BIO_get_new_index-in-OpenSSL-code.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_moadrwve0>
X-Attachment-Id: f_moadrwve0

RnJvbSA4MDA2NzhkYjU2NzRiMDMyMWY2M2ZiNDIwZjk0MmZiNTQzYjhkNzIyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKYWNvYiBDaGFtcGlvbiA8amFjb2IuY2hhbXBpb25AZW50ZXJw
cmlzZWRiLmNvbT4KRGF0ZTogTW9uLCAyMCBBcHIgMjAyNiAxNToyOTo1NCAtMDcwMApTdWJqZWN0
OiBbUEFUQ0hdIFJlbW92ZSBjYWxsIHRvIEJJT19nZXRfbmV3X2luZGV4KCkgaW4gT3BlblNTTCBj
b2RlCgpCSU9fbWV0aF9uZXcoKSB0YWtlcyBhbiAiaW5kZXggdHlwZSIgYXMgaXRzIGZpcnN0IGFy
Z3VtZW50LiBPbGRlcgpPcGVuU1NMIGRvY3VtZW50YXRpb24gdXNlZCB0byBzdWdnZXN0IHRoYXQg
dGhpcyBhcmd1bWVudCBzaG91bGQgYmUKY29uc3RydWN0ZWQgYnkgcmVnaXN0ZXJpbmcgYSBjdXN0
b20gaW5kZXggd2l0aCBCSU9fZ2V0X25ld19pbmRleCgpIGFuZApjb21iaW5pbmcgdGhhdCB3aXRo
IHRoZSBhcHByb3ByaWF0ZSAiQklPIGNsYXNzIiBiaXQuCgpIb3dldmVyLCBjdXN0b20gQklPIGlu
ZGljZXMgYXJlIGFuIGV4dHJlbWVseSBsaW1pdGVkIHJlc291cmNlIFsxXSwgYW5kCm5ld2VyIGRv
Y3VtZW50YXRpb24gc3VnZ2VzdHMgdGhhdCBjbGllbnRzIHNob3VsZCBvbmx5IHRha2Ugb25lIGlm
IHRoZXkKZXhwZWN0IHRvIHNlYXJjaCBhIEJJTyBjaGFpbiBmb3IgaXQgbGF0ZXI6CgogIGB0eXBl
YCBjYW4gYmUgc2V0IHRvIGVpdGhlciBgQklPX1RZUEVfTk9ORWAgb3IgdmlhIEJJT19nZXRfbmV3
X2luZGV4KCkKICBpZiBhIHVuaXF1ZSB0eXBlIGlzIHJlcXVpcmVkIGZvciBzZWFyY2hpbmdbLi4u
XSBOb3RlIHRoYXQKICBCSU9fZ2V0X25ld19pbmRleCgpIGNhbiBvbmx5IGJlIHVzZWQgMTI3IHRp
bWVzIGJlZm9yZSBpdCByZXR1cm5zIGFuCiAgZXJyb3IuCgpXZSBkb24ndCBmYWxsIGludG8gdGhh
dCBjYXRlZ29yeSAod2UgaW1tZWRpYXRlbHkgZGlzY2FyZCB0aGUgaW5kZXggd2UndmUKY3JlYXRl
ZCksIGFuZCBpdCBkb2Vzbid0IGxvb2sgbGlrZSBPcGVuU1NMIGhhcyBldmVyIHJlcXVpcmVkIGEg
bm9uemVybwppbmRleCwgc28gYXZvaWQgcmVnaXN0ZXJpbmcgb25lIGFsdG9nZXRoZXIuCgpQZXIg
Y29tcGxhaW50IGJ5IERhbmllbCBTY2hyZWliZXIgdGhhdCBsaWJwcSBldmVudHVhbGx5IGJyZWFr
cyBPcGVuU1NMCndoZW4gcmVwZWF0ZWRseSBkbG9wZW4vZGxjbG9zZSdkLiBJdCdzIG5vdCBjbGVh
ciB0byBtZSB0aGF0IHdlIHN1cHBvcnQKdGhhdCB1c2UgY2FzZSBpbiBnZW5lcmFsIChyZWxhdGVk
IFRPRE86IGRlY2lkZSB3aGV0aGVyIHRvIGJhY2twYXRjaAp0aGlzKSwgYnV0IHRoaXMgY2hhbmdl
IHNlZW1zIGxpa2UgYSBjbGVhciBpbXByb3ZlbWVudCBnb2luZyBmb3J3YXJkLgoKWzFdIGh0dHBz
Oi8vZ2l0aHViLmNvbS9vcGVuc3NsL29wZW5zc2wvaXNzdWVzLzIzNjU1CgpSZXBvcnRlZC1ieTog
RGFuaWVsIFNjaHJlaWJlciA8ZGFuaWVsLnNjaHJlaWJlckBocnoudHUtY2hlbW5pdHouZGU+CkRp
c2N1c3Npb246IGh0dHBzOi8vcG9zdGdyLmVzL20vZjdmZTM5YjMtN2U5OS00OTM5LTg4NTItMDcz
NTA1NDkxNjFkJTQwaHJ6LnR1LWNoZW1uaXR6LmRlCkJhY2twYXRjaC10aHJvdWdoOiBUT0RPCi0t
LQogc3JjL2JhY2tlbmQvbGlicHEvYmUtc2VjdXJlLW9wZW5zc2wuYyAgICB8IDkgKystLS0tLS0t
CiBzcmMvaW50ZXJmYWNlcy9saWJwcS9mZS1zZWN1cmUtb3BlbnNzbC5jIHwgOCArLS0tLS0tLQog
MiBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL3NyYy9iYWNrZW5kL2xpYnBxL2JlLXNlY3VyZS1vcGVuc3NsLmMgYi9zcmMvYmFja2Vu
ZC9saWJwcS9iZS1zZWN1cmUtb3BlbnNzbC5jCmluZGV4IGEzZTIyMmYzYTNkLi42YzM3MTdiYzAy
NCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvbGlicHEvYmUtc2VjdXJlLW9wZW5zc2wuYworKysg
Yi9zcmMvYmFja2VuZC9saWJwcS9iZS1zZWN1cmUtb3BlbnNzbC5jCkBAIC0xNDE5LDEzICsxNDE5
LDggQEAgcG9ydF9iaW9fbWV0aG9kKHZvaWQpCiB7CiAJaWYgKCFwb3J0X2Jpb19tZXRob2RfcHRy
KQogCXsKLQkJaW50CQkJbXlfYmlvX2luZGV4OwotCi0JCW15X2Jpb19pbmRleCA9IEJJT19nZXRf
bmV3X2luZGV4KCk7Ci0JCWlmIChteV9iaW9faW5kZXggPT0gLTEpCi0JCQlyZXR1cm4gTlVMTDsK
LQkJbXlfYmlvX2luZGV4IHw9IEJJT19UWVBFX1NPVVJDRV9TSU5LOwotCQlwb3J0X2Jpb19tZXRo
b2RfcHRyID0gQklPX21ldGhfbmV3KG15X2Jpb19pbmRleCwgIlBvc3RncmVTUUwgYmFja2VuZCBz
b2NrZXQiKTsKKwkJcG9ydF9iaW9fbWV0aG9kX3B0ciA9IEJJT19tZXRoX25ldyhCSU9fVFlQRV9T
T1VSQ0VfU0lOSywKKwkJCQkJCQkJCQkgICAiUG9zdGdyZVNRTCBiYWNrZW5kIHNvY2tldCIpOwog
CQlpZiAoIXBvcnRfYmlvX21ldGhvZF9wdHIpCiAJCQlyZXR1cm4gTlVMTDsKIAkJaWYgKCFCSU9f
bWV0aF9zZXRfd3JpdGUocG9ydF9iaW9fbWV0aG9kX3B0ciwgcG9ydF9iaW9fd3JpdGUpIHx8CmRp
ZmYgLS1naXQgYS9zcmMvaW50ZXJmYWNlcy9saWJwcS9mZS1zZWN1cmUtb3BlbnNzbC5jIGIvc3Jj
L2ludGVyZmFjZXMvbGlicHEvZmUtc2VjdXJlLW9wZW5zc2wuYwppbmRleCBmYmQzYzYzZmI1ZC4u
MjIxNGExNDE4NDcgMTAwNjQ0Ci0tLSBhL3NyYy9pbnRlcmZhY2VzL2xpYnBxL2ZlLXNlY3VyZS1v
cGVuc3NsLmMKKysrIGIvc3JjL2ludGVyZmFjZXMvbGlicHEvZmUtc2VjdXJlLW9wZW5zc2wuYwpA
QCAtMTg0MSwxMyArMTg0MSw3IEBAIHBnY29ubl9iaW9fbWV0aG9kKHZvaWQpCiAKIAlpZiAoIXBn
Y29ubl9iaW9fbWV0aG9kX3B0cikKIAl7Ci0JCWludAkJCW15X2Jpb19pbmRleDsKLQotCQlteV9i
aW9faW5kZXggPSBCSU9fZ2V0X25ld19pbmRleCgpOwotCQlpZiAobXlfYmlvX2luZGV4ID09IC0x
KQotCQkJZ290byBlcnI7Ci0JCW15X2Jpb19pbmRleCB8PSBCSU9fVFlQRV9TT1VSQ0VfU0lOSzsK
LQkJcmVzID0gQklPX21ldGhfbmV3KG15X2Jpb19pbmRleCwgImxpYnBxIHNvY2tldCIpOworCQly
ZXMgPSBCSU9fbWV0aF9uZXcoQklPX1RZUEVfU09VUkNFX1NJTkssICJsaWJwcSBzb2NrZXQiKTsK
IAkJaWYgKCFyZXMpCiAJCQlnb3RvIGVycjsKIAotLSAKMi4zNC4xCgo=
--000000000000928dcd065010b544--