RE: Using ProcSignal to get memory context stats from a runningbackend - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Using ProcSignal to get memory context stats from a runningbackend
Date
Msg-id 0A3221C70F24FB45833433255569204D1F84C9AA@G01JPEXMBYT05
Whole thread Raw
In response to Using ProcSignal to get memory context stats from a running backend  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Using ProcSignal to get memory context stats from a running backend  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
From: Craig Ringer [mailto:craig@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
backgroundworkers, etc. that connect to shared memory?
 

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?
 

Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] Pluggable storage
Next
From: Andres Freund
Date:
Subject: Re: Using ProcSignal to get memory context stats from a runningbackend