On 2014-06-23 08:36:02 -0400, Stephen Frost wrote:
> 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..
prior to SQL access := Before crash recovery finished/hot standby
reached consistency.
And I don't agree that memory dumps from non-plain backends are that
uninteresting. E.g. background workers and logical decoding walsenders
both can be interesting.
> 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?
I think these are *much* more complicated. I don't want to tackle them
at the same time, otherwise we'll never get anywhere.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
