Re: [HACKERS] Runtime Partition Pruning
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | CA+TgmoZb92kFnJ6bTr8awM5TKh15e2fZL6rzoNA515i=CX1kRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: