Removing the TRACE_SORT macro

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Removing the TRACE_SORT macro
Date: 2016-04-11 20:43:06
Message-ID: CAM3SWZRaY9XaLPtx7aAPo3sEahk+6ExLX7+5Y=h-ECcy05phOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Peter Geoghegan

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2016-04-11 20:53:56 Re: Choosing parallel_degree
Previous Message Robert Haas 2016-04-11 19:37:32 Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0