Re: Backend memory dump analysis

Andres Freund <andres@anarazel.de> writes:
> On 2018-03-23 15:12:43 -0400, Tom Lane wrote:
>> 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.

You could imagine adding *two* pointers to memory contexts, a callback
function and an arg to pass to it, so that the callback localizes the
knowledge of how to dig an identifier string out of whatever struct
is involved.  I really doubt this is worth that much overhead though.
I think all of the actually interesting cases have a string available
already (though I might find out differently while doing the patch).
Furthermore, if they don't have a string available already, I'm not
real clear on how the callback would create one without doing a palloc.

> 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.

Not for extensions, eg PLs, which would be one of the bigger use-cases
IMO.

			regards, tom lane