pgsql: Fix assorted pretty-trivial memory leaks in the backend.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Fix assorted pretty-trivial memory leaks in the backend.
Дата
Msg-id E1uiO1p-000So5-2l@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Fix assorted pretty-trivial memory leaks in the backend.

In the current system architecture, none of these are worth obsessing
over; most are once-per-process leaks.  However, Valgrind complains
about all of them, and if we get to using threads rather than
processes for backend sessions, it will become more interesting to
avoid per-session leaks.

* Fix leaks in StartupXLOG() and ShutdownWalRecovery().

* Fix leakage of pq_mq_handle in a parallel worker.
While at it, move mq_putmessage's "Assert(pq_mq_handle != NULL)"
to someplace where it's not trivially useless.

* Fix leak in logicalrep_worker_detach().

* Don't leak the startup-packet buffer in ProcessStartupPacket().

* Fix leak in evtcache.c's DecodeTextArrayToBitmapset().
If the presented array is toasted, this neglected to free the
detoasted copy, which was then leaked into EventTriggerCacheContext.

* I'm distressed by the amount of code that BuildEventTriggerCache
is willing to run while switched into a long-lived cache context.
Although the detoasted array is the only leak that Valgrind reports,
let's tighten things up while we're here.  (DecodeTextArrayToBitmapset
is still run in the cache context, so doing this doesn't remove the
need for the detoast fix.  But it reduces the surface area for other
leaks.)

* load_domaintype_info() intentionally leaked some intermediate cruft
into the long-lived DomainConstraintCache's memory context, reasoning
that the amount of leakage will typically not be much so it's not
worth doing a copyObject() of the final tree to avoid that.  But
Valgrind knows nothing of engineering tradeoffs and complains anyway.
On the whole, the copyObject doesn't cost that much and this is surely
not a performance-critical code path, so let's do it the clean way.

* MarkGUCPrefixReserved didn't bother to clean up removed placeholder
GUCs at all, which shows up as a leak in one regression test.
It seems appropriate for it to do as much cleanup as
define_custom_variable does when replacing placeholders, so factor
that code out into a helper function.  define_custom_variable's logic
was one brick shy of a load too: it forgot to free the separate
allocation for the placeholder's name.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Richard Guo <guofenglinux@gmail.com>
Discussion: https://postgr.es/m/285483.1746756246@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e78d1d6d47dc7f04fb59fddfc38bab73ec8f1e82

Modified Files
--------------
src/backend/access/transam/xlog.c          | 33 +++++++++++++++++---------
src/backend/access/transam/xlogrecovery.c  |  1 +
src/backend/libpq/pqmq.c                   | 16 +++++++++----
src/backend/replication/logical/launcher.c |  2 ++
src/backend/tcop/backend_startup.c         | 33 ++++++++++++++++++--------
src/backend/utils/cache/evtcache.c         | 16 +++++++------
src/backend/utils/cache/typcache.c         | 13 +++++-----
src/backend/utils/misc/guc.c               | 38 ++++++++++++++++++++----------
8 files changed, 99 insertions(+), 53 deletions(-)


В списке pgsql-committers по дате отправления: