Re: Removing the TRACE_SORT macro

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Removing the TRACE_SORT macro
Дата
Msg-id CANP8+jK8hh9EAHnLw+sQA4=f3oGzWzpDDjQAvWmW17nh9vHGOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Removing the TRACE_SORT macro  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Removing the TRACE_SORT macro  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 11 April 2016 at 21:43, Peter Geoghegan <pg@heroku.com> wrote:
Currently, debug instrumentation for sorting is only available if the
TRACE_SORT macro was defined when PostgreSQL was compiled. It is
defined by default, and so in practice it's always available; there is
really no upside to disabling it. "18.17. Developer Options" notes
this restriction for trace_sort, which is the only such restriction.

The number of TRACE_SORT elog() logging callers has grown
significantly in the past couple of releases. The associated "#ifdef
TRACE_SORT" crud has also grown.

I propose that we completely remove the TRACE_SORT macro, and all the
associated crud. Just having that as an option suggests that there is
some possible upside to disabling trace_sort, which is clearly not
true. I will write a patch doing this if there are no objections. I
think this is justifiable as clean-up for 9.6.

Yeh, sort has changed enough now that fixes weren't going to backpatch cleanly, so its a good time to do cleanup. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Choosing parallel_degree
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Remove unused function from walsender.c