On Wed, May 29, 2019 at 6:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, it *is* a problem. The whole point of this discussion I think is
> to try to get better information "by default" for routine bug reports.
> So if those come from production servers without debug symbols, which
> I believe will be the usual case, then it seems likely to me that
> libunwind will produce no better results than glibc. (But perhaps
> I'm wrong about that --- I have not experimented with libunwind.)
Sure, I agree.
> Now it's true that "install debug symbols" is less of an ask than
> "install debug symbols, *and* gdb, and make sure server core dumps are
> enabled, and then go through this arcane manual procedure next time
> you get a core dump". But we shouldn't fool ourselves that it isn't
> an ask that's going to be hard for people with corporate policies
> against installing extra stuff on production servers.
There may be cases where that is true, but as you say, it's better
than what we have now. Plus, what exactly is the alternative? We
could:
- encourage packagers to install debug symbols by default (but they
might not; it might even be against policy), or
- invent our own system for generating backtraces and ignore what the
OS toolchain knows how to do (sounds painfully complex and expensive),
or
- just live with the fact that it's imperfect.
Is there a fourth option?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
