On 12 December 2017 at 14:06, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > 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:
typedef void (*printwrapper)(void *extra, const char *fmt,...)
pg_attribute_printf(2, 3);
...
static void
printwrapper_stderr(void *extra, const char *fmt, ...)
{
vfprintf(stderr, fmt, va_list);
}
void
MemoryContextStats(MemoryContext context)
{
MemoryContextStatsDetail(context, 100, printwrapper_stderr, NULL);
}
void
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.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
