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.) 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers