Using ProcSignal to get memory context stats from a running backend

Hi all

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?

I fairly frequently want to get a memory context dump from a running
backend. It's trivial to do on a debug-enabled build (or one with debug
symbols packages installed) when on a system with gdb and when I'm the one
driving.

Frequently one or more of these things are not true. Users rarely install
debug symbols packages, and never build with --enable-debug if building
from source. They rarely have gdb to hand, and rarely know how to use it if
they do.

So getting memory context dumps from backends showing signs of unreasonable
memory bloat is harder than would be ideal for such incredibly handy debug
info. Especially since most users run with default overcommit on Linux, so
Linux likes to nuke the process rather than let us print context dumps when
we detect OOM.

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.

We could clobber a prior ProcSignalReason set on the proc, but that's why
we retry.

Way, way easier than getting gdb and debuginfo in place, attaching, etc.
You still have to go fishing for stderr to find the output, but that's
usually the same place as the rest of the logs.

Barring objections I'll send a patch in a while.

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