diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2025-05-22 20:35:32 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2025-05-22 20:35:32 -0400 |
commit | b7ab88ddb1b9872cd997aea921df99eed8ac220b (patch) | |
tree | 270bf7e9b7a75083a118564ccfc7a682296180f2 /src/backend/port/dynloader/unixware.c | |
parent | cb1456423d3925f9c70a488b58f03f186561f00f (diff) | |
download | postgresql-b7ab88ddb1b9872cd997aea921df99eed8ac220b.tar.gz postgresql-b7ab88ddb1b9872cd997aea921df99eed8ac220b.zip |
Fix assorted new memory leaks in libpq.
Valgrind'ing the postgres_fdw tests showed me that libpq was leaking
PGconn.be_cancel_key. It looks like freePGconn is expecting
pqDropServerData to release it ... but in a cancel connection
object, that doesn't happen.
Looking a little closer, I was dismayed to find that freePGconn
also missed freeing the pgservice, min_protocol_version,
max_protocol_version, sslkeylogfile, scram_client_key_binary,
and scram_server_key_binary strings. There's much less excuse
for those oversights. Worse, that's from five different commits
(a460251f0, 4b99fed75, 285613c60, 2da74d8d6, 761c79508),
some of them by extremely senior hackers.
Fortunately, all of these are new in v18, so we haven't
shipped any leaky versions of libpq.
While at it, reorder the operations in freePGconn to match the
order of the fields in struct PGconn. Some of those free's seem
to have been inserted with the aid of a dartboard.
Diffstat (limited to 'src/backend/port/dynloader/unixware.c')
0 files changed, 0 insertions, 0 deletions