Andres,
* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2014-06-23 08:36:02 -0400, Stephen Frost wrote:
> > 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.
I didn't mean they're uninteresting- I meant that if you're dealing with
those kinds of issues, having gdb isn't as huge a hurdle..
> > 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.
Sure, just some things to keep in mind as you're thinking about changes
in this area. Just to toss another random thought out there, what about
an SQL function which does a LISTEN and then sends a signal to another
backend which throws a NOTIFY with payload including the requested info?
That'd be *very* useful as there are lots of cases where access to the
logs isn't trivial (particularly if they've been properly locked down
due to the sensetive info they can contain..).
Thanks,
Stephen
