> Another question is whether printing to stderr, bypassing proper > logging!, is good enough for something like this.
Yeah, this is an issue. MemoryContextStats is designed to print to stderr in the (possibly vain) hope that it will work even when we are up against an OOM failure. That's not a property I much want to give up, but you're right that it's not very desirable if a user is trying to capture state during normal running.
If we were willing to wrap variadic calls in a callback and rely on vfprintf, we could:
MemoryContextStatsDetail(MemoryContext context, int max_children,
printwrapper outfunc, void *printwrapper_extra)
{
...
printwrapper(extra, "Grand total: ...", ...);
}
and let the ProcSignal based caller pass an elog wrapper instead, or form a StringInfo with appendStringInfoVA then elog it in one go after the MemoryContextStatsDetail call returns.
I was worried about relying on vfprintf, but we already use it widely in the codebase so it shouldn't be an issue with elderly buildfarm critters.
Letting it go to stderr isn't too bad, but it'd certainly make it that bit nicer if it didn't so I'm not opposed to adding the needed indirection. I'll give it a try in a bit.
