On Fri, May 24, 2019 at 12:09 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Is it actually better? The basic problem with backtrace() is that it > only knows about global functions, and so reports call sites in static > functions as if they were in whatever global function physically precedes > the static one. I think doing materially better requires depending on > debug symbols, which (at least in the Red Hat world) aren't going to > be there in a typical production situation.
I don't have an opinion on glibc vs. libunwind, but I don't understand this argument. If you are unlucky enough to have a production server that is crashing due to some hitherto-unknown bug, and if it's not possible to get a good backtrace without installing debugging symbols, then you are going to have to pick between (1) installing those debugging symbols and (2) getting a poor backtrace. I don't really see that as a problem so much as just the way life is. You can't expect to get good debugging output without debugging symbols, just as you can't expect to get a clean audit without bank statements or a clear idea of how to find your way to an unknown destination without a map. If you don't have the thing that contains the information that is needed, you can't get the information; c'est la vie. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company