| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Allow pg_log_backend_memory_contexts() for postmaster |
| Date: | 2026-06-22 19:36:09 |
| Message-ID: | cdg2nixu36v6ftun366m3eypjrpsi5egspxhq23bbn4qhltmcg@olie7ip7yx4b |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-06-22 15:15:27 +0200, Jakub Wartak wrote:
> During one of recent investigations about memory leaks in postmaster, I was
> quite tired of issues related to gdb (it's seems very risky on postmaster,
> requires for gdb to be installed and might cause friction).
>
> I was wondering why we couldn't suppport this out of the box. It looks like
> useful addition to me, so here's the patch.
I agree it'd be useful, but I think it'd be somewhat risky to allow. If you
have some sort of memory leak issue in postmaster,
ProcessLogMemoryContextInterrupt() could take a while without responding to
incoming client connections, responding to signals etc (e.g. because there are
many memory contexts, or because the log destination is slow processing a lot
of output). Maybe that would practically be ok, but I'm not sure it will.
At least on !EXEC_BACKEND systems you can get the data in a forked process,
before the forked process does MemoryContextDelete(PostmasterContext). In
theory you could rig things up so that the child logs the memory context
information. However that currently is probably not doable because we won't
accept interrupts before the MemoryContextDelete()...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2026-06-22 19:39:36 | The PostgreSQL C Dialect |
| Previous Message | Corey Huinker | 2026-06-22 19:08:33 | Re: use of SPI by postgresImportForeignStatistics |