Re: pgsql: Add function to get memory context stats for processes
Daniel Gustafsson <dgustafsson@postgresql.org>
From: Daniel Gustafsson <dgustafsson@postgresql.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Rahila Syed <rahilasyed90@gmail.com>
Date: 2025-04-22T08:11:43Z
Lists: pgsql-hackers
> On 17 Apr 2025, at 16:42, Robert Haas <robertmhaas@gmail.com> 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 do not believe we have > anywhere enough guarantees about reentrancy for that to be safe. Do you mean that an interrupt handler will make DSA allocations? I don't think that would be something we'd want to allow regardless of this patch. Or did I misunderstand the above? -- Daniel Gustafsson
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