Re: pgsql: Add function to get memory context stats for processes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pgsql: Add function to get memory context stats for processes
Date
Msg-id rznpn3hfiojkn2g647kspne42swrzsjf7logaqeyl2zsyyzj5p@bfq63rw4zltd
Whole thread Raw
In response to Re: pgsql: Add function to get memory context stats for processes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2025-04-17 10:42:45 -0400, Robert Haas wrote:
> On Tue, Apr 15, 2025 at 6:11 AM Andres Freund <andres@anarazel.de> wrote:
> > There very well could be a CFI - but it better be somewhere where the
> > in-memory state is consistent. Otherwise an error inside raised in the CFI
> > would lead the in-memory state inconsistent which then would cause problems
> > when cleaning up the dsa during resowner release or process exit.
> >
> > What am I missing here?
> 
> I think maybe you're only thinking about gathering the data. What
> about publishing it? If the DSA code were interrupted at a CFI and the
> interrupting code went and tried to perform a DSA allocation to store
> the resulting data and then returned to the interrupted DSA operation,
> would you expect the code to cope with that?

I would expect the DSA code to not call CFI() in such a place - afaict nearly
all such cases would also not be safe against errors being raised in the CFI()
and then later again allocating memory from the DSA (or resetting
it). Similarly, aset.c better not accept interrupts in the middle of, e.g.,
AllocSetAllocFromNewBlock(), since we'd loose track of the allocation.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Cygwin support
Next
From: Tom Lane
Date:
Subject: Re: Fortify float4 and float8 regression tests by ordering test results