Re: Enhancing Memory Context Statistics Reporting
Rahila Syed <rahilasyed90@gmail.com>
From: Rahila Syed <rahilasyed90@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Daniel Gustafsson <daniel@yesql.se>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-07T18:30:54Z
Lists: pgsql-hackers
> > > > That's not an argument against moving it to BaseInit() though, as that's > called before procsignal is even initialized and before signals are > unmasked. > Yes, OK. > I don't really understand why DSA_DEFAULT_INIT_SEGMENT_SIZE is > > > > something that makes sense to use here? > > > > > > > > To determine the memory limit per backend in multiples of > > DSA_DEFAULT_INIT_SEGMENT_SIZE. > > Currently it is set to 1 * DSA_DEFAULT_INIT_SEGMENT_SIZE. > > Since a call to dsa_create would create a DSA segment of this size, I > > thought it makes sense > > to define a limit related to the segment size. > > I strongly disagree. The limit should be in an understandable unit, not on > another subystems's defaults that might change at some point. > OK, makes sense. > > > > > + /* If the dsm mapping could not be found, attach to the area */ > > > > + if (dsm_seg != NULL) > > > > + return; > > > > > > I don't understand what we do here with the dsm? Why do we not need > > > cleanup > > > if we are already attached to the dsm segment? > > > > > > > I am not expecting to hit this case, since we are always detaching from > the > > dsa. > > Pretty sure it's reachable, consider a failure of dsa_allocate(). That'll > throw an error, while attached to the segment. > > You are right, I did not think of this scenario. > > > This could be an assert but since it is a cleanup code, I thought > returning > > would be a harmless step. > > The problem is that the code seems wrong - if we are already attached we'll > leak the memory! > > I understand your concern. One issue I recall is that we do not have a dsa_find_mapping function similar to dsm_find_mapping(). If I understand correctly, the only way to access an already attached DSA is to ensure we store the DSA area mapping in a global variable. I'm considering using a global variable and accessing it from the cleanup function in case it is already mapped. Does that sound fine? > As I also mentioned, I don't understand why we're constantly > attaching/detaching from the dsa/dsm either. It just seems to make things > more > complicated an dmore expensive. > OK, I see that this could be expensive if a process is periodically being queried for statistics. However, in scenarios where a process is queried only once for memory, statistics, keeping the area mapped would consume memory resources, correct? Thank you, Rahila Syed
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Cross-check lists of built-in LWLock tranches.
- 2047ad068139 19 (unreleased) cited
-
Convert strncpy to strlcpy
- 45e7e8ca9e93 18.0 landed
-
Typo and doc fixups for memory context reporting
- f8c115a6cb65 18.0 landed
-
Add missing string terminator
- d2a1ed1727a8 18.0 landed
-
Rename argument in pg_get_process_memory_contexts().
- c57971034e69 18.0 landed
-
Add function to get memory context stats for processes
- 042a66291b04 18.0 landed