Re: Using ProcSignal to get memory context stats from a running backend
От | Craig Ringer |
---|---|
Тема | Re: Using ProcSignal to get memory context stats from a running backend |
Дата | |
Msg-id | CAMsr+YEjvM8-CT5vWWxn=wT7Oz3dAuntOoZP75NLfVSR=eAD2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using ProcSignal to get memory context stats from a runningbackend (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Using ProcSignal to get memory context stats from a running backend
|
Список | pgsql-hackers |
On 12 December 2017 at 12:43, Andres Freund <andres@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.
В списке pgsql-hackers по дате отправления: