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

On 12 December 2017 at 12:25, Tsunakawa, Takayuki <
tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:

> From: Craig Ringer [mailto:craig(at)2ndquadrant(dot)com]
> > 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?
>
> > So how about borrowing a ProcSignalReason entry for "dump a memory
> context
> > summary at your earliest convenience" ? We could name it a more generic
> > "dump debug data" in case we want to add things later.
> >
> > Then a new pg_log_debug_backend(int) function or something like that
> could
> > signal the proc and let CHECK_FOR_INTERRUPTS handle calling
> > MemoryContextStats next time it's called.
>
> +1
> That's one of things I wanted to do. It will be more useful on Windows.
> Would it work for autovac processes and background workers, etc. that
> connect to shared memory?
>

Anything that uses CHECK_FOR_INTERRUPTS() and is attached to PGXACT. So
yeah, pretty much anything attached to shmem.

> I have also wanted to dump stack traces. Linux (glibc) has
> backtrace_symbols(), and Windows has StackWalk()/StackWalk64(). Is it sane
> to make the function a hook?
>

In-proc stack traces are immensely useful, and IMO relatively safe in a
proc that's already in a reasonable state. If your stack is mangled, making
it worse with an in-proc stack trace is rarely your biggest concern. I'd
LOVE to be able to do this.

However, I'd want to address anything like that quite separately to the
change I proposed to expose an existing facility.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services