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.