Re: pgsql: Add function to get memory context stats for processes

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Daniel Gustafsson <dgustafsson(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Rahila Syed <rahilasyed90(at)gmail(dot)com>
Subject: Re: pgsql: Add function to get memory context stats for processes
Date: 2025-04-10 20:05:42
Message-ID: zppwd3scfznxhptdwm765l73wttegi5mibaxyxdwihlmzg3khs@fdhzkq3uxyct
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hi,

On 2025-04-10 09:31:00 -0400, Robert Haas wrote:
> On Tue, Apr 8, 2025 at 5:10 AM Daniel Gustafsson
> <dgustafsson(at)postgresql(dot)org> wrote:
> > Add function to get memory context stats for processes
>
> Apologies if this has already been discussed, but what is the argument
> that it is safe to do everything in ProcessGetMemoryContextInterrupt()
> at an arbitrary CHECK_FOR_INTERRUPTS() call? We have
> CHECK_FOR_INTERRUPTS() calls in some quite low-level places, such as
> walkdir() and copydir(). I don't think there's any guarantee that it's
> safe to perform DSA operations at an arbitrary place where
> CHECK_FOR_INTERRUPTS() is called, and I'm not even quite sure that
> it's safe to assume that the local memory-context tree is in a
> consistent state when CHECK_FOR_INTERRUPTS() is called.

I don't know of existing discussion, but it seems rather fundamental to me -
if either DSA or memory contexts could be inconsistent at a CFI(), how could
it possibly be safe to interrupt at that point? After all, after an error you
need to be able to reset the memory contexts / release memory in a
dsa/dshash/whatnot? Memory context reset requires walking over the allocations
made in the context, similar releasing a dsa?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Daniel Gustafsson 2025-04-10 21:03:18 pgsql: Rename global variable backing DSA area
Previous Message Andrew Dunstan 2025-04-10 18:57:20 pgsql: Fix memory leak in pg_restore.c

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-04-10 20:05:48 Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
Previous Message Tom Lane 2025-04-10 19:54:39 Re: Reduce "Var IS [NOT] NULL" quals during constant folding