From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Use a signal to trigger a memory context dump? |
Date: | 2014-06-23 17:07:36 |
Message-ID: | 17139.1403543256@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.)
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-06-23 17:07:51 | Re: Minmax indexes |
Previous Message | Robert Haas | 2014-06-23 17:07:22 | checking for interrupts during heap insertion |