On 12 December 2017 at 12:25, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Craig Ringer [mailto:cr...@2ndquadrant.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
