Andres, * Andres Freund (and...@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
signature.asc
Description: Digital signature