Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id 16007.1558711252@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2018-04-10 23:32, Alvaro Herrera wrote:
>> To figure out, I used the attached patch (not intended for application)
>> to add a backtrace to each log message, plus a couple of accusatory
>> elog() calls in relation_open and ExecSetupPartitionPruneState.

> What do people think about adding something like this errbacktrace()
> from Álvaro's patch to core PostgreSQL?  If we could devise a way to
> selectively enable it, it might be an easier way for users to provide
> backtraces from errors.

I think we did discuss it right after that, or somewhere nearby, and
concluded that the output is so imprecise that it's not really going
to be worth whatever portability issues we'd have to deal with.

I'd be all for a better version, but glibc's backtrace() just sucks,
at least given our coding style with lots of static functions.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL