Re: Backend memory dump analysis

On 2018-03-23 15:12:43 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
> >> +   MemoryContextSetIdentifier(func_cxt, function->fn_signature);
> >> 
> >> This would cost an extra char * field in struct MemoryContextData,
> >> which is slightly annoying but it doesn't exactly seem like a killer.
> >> Then the memory stats dump code would just need to know to print this
> >> field if it isn't NULL.
> 
> > That's not a bad idea. How about storing a Node* instead of a char*?
> > Then we could have MemoryContextStats etc support digging out details
> > for a few types, without having to generate strings at runtime.
> 
> Well, in the cases I'm thinking of at the moment, there's no handy Node
> to point at, just module-private structs like PLpgSQL_function.

Well, the cases Vladimir were concerned about seem less clear
though. It'd be nice if we could just point to a CachedPlanSource and
such.


> So doing anything like that would add nonzero overhead to construct
> something.

I'm not that sure there aren't easy way to overcome those - couldn't we
"just" make FmgrInfo etc be tagged types? The space overhead of that
can't matter in comparison to the size of the relevant structs.


> There's also the fact that we don't want MemoryContextStats doing
> anything very complicated, because of the risk of failure and the
> likelihood that any attempt to palloc would fail (if we're there
> because we're up against OOM already).

That's true. But I'm not sure there's a meaningful difference in risk
here. Obviously you shouldn't try to print a node tree or something, but
an if statement looking 

Greetings,

Andres Freund