Re: Backend memory dump analysis

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> My only gripe is the pattern where the identifier needs to be
> re-installed when resetting the context.  I don't think we need to hold
> push for that reason alone, but I bet we'll be revisiting that.

Yeah, that's slightly annoying; if I'd found more than one case of that,
I'd want a better answer.  But it seems like contexts that are long-lived
enough to warrant labeling typically don't get reset during their
lifespans, so it shouldn't be a huge problem.

I considered having MemoryContextReset either Assert that context->ident
is NULL, or just forcibly reset it to NULL, thus preventing a dangling
pointer if someone gets this wrong.  But that would lock out a perfectly
valid coding pattern where the identifier is in the parent context, so
I'm not convinced it's a good idea.

> I suppose this infrastructure can be used to implement the idea in
> https://www.postgresql.org/message-id/CAMsr+YHii-BCC7ddpbb8fpCgzt0wMRt5GYZ0W_kD_Ft8rwWPiQ@mail.gmail.com
> in some more acceptable manner.  I'm not proposing it for now, just
> parking the idea for a future patch.

Ah, I thought I remembered the callback idea from some previous
discussion, but I'd not located this one.  I think I've got a nicer
API for the per-context-type stats functions than what Craig
proposes there, but we could imagine doing this API or something
close to it for MemoryContextStatsInternal.  Or, as I mentioned
before, an external caller could just implement the scan over the
context tree for itself, and format the data however it wants.

			regards, tom lane