On 2014-06-23 10:07:36 -0700, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers