On 12 December 2017 at 12:43, Andres Freund <and...@anarazel.de> wrote:
> 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. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
