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
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 |