Re: Using ProcSignal to get memory context stats from a running backend - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Using ProcSignal to get memory context stats from a running backend
Date
Msg-id CAMsr+YHUX1F8yCi=awoe=xHu918JRgyVf6gTcLnp1iQZuioFJg@mail.gmail.com
Whole thread Raw
In response to RE: Using ProcSignal to get memory context stats from a runningbackend  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On 12 December 2017 at 12:25, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
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 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: alternative psql commands quit and exit
Next
From: Dilip Kumar
Date:
Subject: Re: Boolean partitions syntax