On Wed, Apr 1, 2026 at 2:34 AM Lukas Fittl <[email protected]> wrote: > Is there a reason you didn't use GetNamedDSA / GetNamedDSHash for the > other allocations? (which we have as of fe07100e82b09)
I'm under the impression that GetNamedDSA and GetNamedDSHash exist for the purposes of making it easy for extensions to coordinate with each other across backends, rather than being something you're supposed to use to improve observability. I think it's potentially good for there to be a way to see the size of every DSA that exists in the system, but this clearly isn't that, because none of the code in src/backend uses it when creating DSAs. You might argue that DSAs for short-lived things like parallel query or parallel VACUUM don't need to be tracked like this (which seems arguable), but they are also used for long-lived contexts in the logical replication launcher, by LISTEN/NOTIFY, by the shared-memory statistics collector, and in GetSessionDsmHandle(), and those places don't use GetNamedDSA() either. Architecturally, I don't like the idea of replacing "having a pointer to an object" with "being able to look up that object by name". I think it's good design that pg_stash_advice creates one structure that serves as a sort of root and then hangs everything else off of that. I admit that leaves me not knowing quite what to do about the problem of knowing how much memory it's using, though. Adding a function just to return size information seems a little clunky, but it might be the right idea: it could for example return a count of stashes, a count of entries, the total length of the entries, and the allocated size of the DSA. -- Robert Haas EDB: http://www.enterprisedb.com
