Re: Use a signal to trigger a memory context dump?

On 2014-06-23 10:07:36 -0700, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > I wonder if it'd make sense to allow a signal to trigger a memory
> > context dump? I and others more than once had the need to examine memory
> > usage on production systems and using gdb isn't always realistic.
> > I wonder if we could install a signal handler for some unused signal
> > (e.g. SIGPWR) to dump memory.
> > I'd also considered adding a SQL function that uses the SIGUSR1 signal
> > multiplexing for the purpose but that's not necessarily nice if you have
> > to investigate while SQL access isn't yet possible. There's also the
> > problem that not all possibly interesting processes use the sigusr1
> > signal multiplexing.
>
> Well, you can't just have the signal handler call MemoryContextStats
> directly. (Even if the memory manager's state were 100% interrupt-safe,
> which it ain't, fprintf itself might not be safe either.)

Yea. And fprintf() definitely isn't.

> The closest approximation that I think would be reasonable is to
> set a flag that would be noticed by the next CHECK_FOR_INTERRUPTS
> macro. So you're already buying into the assumption that the process
> executes CHECK_FOR_INTERRUPTS fairly often. Which probably means
> that assuming it's using the standard sigusr1 handler isn't a big
> extra limitation.

There seem to be far more subsystems doing CHECK_FOR_INTERRUPTS than
using SIGUSR1 multiplexing. Several processes have their own SIGUSR1
handlers:
* bgworkers (Which certainly is a major candidate for this. And: Isn't this a bug?
Think recovery conflicts.)
* startup process (certainly interesting as well)
* checkpointer
* walreceiver
* walsender
* wal writer
* bgwriter
* archiver
* syslogger

At least bgworkers, startup process, walsenders are definitely
interesting from this POV.

It very well might be best to provide a common sigusr1 implementation
supporting a subset of multiplexing for some of those since they
essentially all do the same... Although that'd require a fair bit of
surgery in procsignal.c

Greetings,

Andres Freund

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