Andres,
* Andres Freund (andres@2ndquadrant.com) wrote:
> 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.
+100
I keep thinking we have this and then keep being disappointed when I go
try to find it.
> I wonder if we could install a signal handler for some unused signal
> (e.g. SIGPWR) to dump memory.
Interesting thought, but..
> 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.
I'd tend to think this would be sufficient. You're suggesting a case
where you need to debug prior to SQL access (not specifically sure what
you mean by that) or processes which are hopefully less likely to have
memory issues, but you don't have gdb..
Another thought along the lines of getting information about running
processes would be to see the call stack or execution plan.. I seem to
recall there being a patch for the latter at one point?
Thanks,
Stephen
