Re: Allow pg_log_backend_memory_contexts() for postmaster

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

In response to

Responses

Browse pgsql-hackers by date

  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