Re: pgsql: Add function to get memory context stats for processes
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Daniel Gustafsson <dgustafsson@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Rahila Syed <rahilasyed90@gmail.com>
Date: 2025-04-10T20:05:42Z
Lists: 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@postgresql.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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rename global variable backing DSA area
- 55ef7abf88c0 18.0 landed
-
Add function to get memory context stats for processes
- 042a66291b04 18.0 cited