Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed |
| Дата | |
| Msg-id | 1881734.1771354069@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed (PG Bug reporting form <noreply@postgresql.org>) |
| Ответы |
Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed
RE: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed |
| Список | pgsql-bugs |
Matt Carter <Matt.Carter@twosigma.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think there are way too many moving parts here, and too few configuration details,
>> to allow assigning blame confidently.
> Thank you for taking the time to test this and for the feedback. Your C test showing no leak suggests the issue is
specificto how psycopg2 uses libpq, not libpq itself. I apologize for not including enough environmental details. I
usedKerberos/GSSAPI with SSL (TLS 1.2 connections). My connection string was: "postgresql://hostname/database" (no
password,Kerberos auth).
> Your mention of "years ago libpq did leak memory while using GSSAPI encryption" is interesting because we ARE using
GSSAPI/Kerberosauthentication.
Interesting. I wondered about GSSAPI, but spinning up such an
environment is more work than I wanted to do on speculation.
> I can test with non-GSSAPI authentication to try to isolate that variable. I can also create a pure psycopg2
reproducer(without SQLAlchemy). I can also test whether disabling GSSAPI encryption (but keeping GSSAPI auth) changes
thebehavior. Would testing with GSSAPI authentication help narrow this down? I can also report this to the psycopg2
projectif you think it's their issue.
Please try varying the connection type and encryption. I do suspect
this may be psycopg2's fault, but we lack enough data to pin blame
as yet.
regards, tom lane
В списке pgsql-bugs по дате отправления: