RE: Using ProcSignal to get memory context stats from a runningbackend
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Using ProcSignal to get memory context stats from a runningbackend |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F84C9AA@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Using ProcSignal to get memory context stats from a running backend (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Using ProcSignal to get memory context stats from a running backend
|
Список | 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 по дате отправления: