Re: Using ProcSignal to get memory context stats from a running backend

On 12 December 2017 at 12:43, Andres Freund <andres(at)anarazel(dot)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