Hi, On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > TL;DR: Lets add a ProcSignalReason that makes a backend > call MemoryContextStats when it sees it and a C func that users can use to > set it on a proc. Sane?
It's not unproblematic. procsignal_sigusr1_handler() runs in a signal handler, so you can't really rely on a lot of stuff being legal to do.
It'd be easy to set a flag in the handler and then have CHECK_FOR_INTERRUPTS() do the MemoryContextStats() call.
Yes, definitely. That was my intention. Trying to write to stderr, mess with memory contexts, etc from a signal handler context seems awfully hairy and definitely not something I'd want to risk on a live system.
But that'd have the disadvanatage that it possibly would take a while till the MemoryContextStats() is executed. Not sure if that's still good enough for you?
Definitely. Sure, it won't be perfect, but it'd be a big improvement on what we have.
Another question is whether printing to stderr, bypassing proper logging!, is good enough for something like this.
I think the reason it prints to stderr now is that it's intended to run in OOM situations.
Arguably that's not such a concern when being triggered by a procsignal. So elog(...) in that context could make sense. I'd probably add a print-wrapper callback arg to MemoryContextStatsDetail that you can use to write to a stringinfo / elog / fprintf(stderr), as desired.
