From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Removing the TRACE_SORT macro |
Date: | 2016-04-11 21:35:28 |
Message-ID: | CANP8+jK8hh9EAHnLw+sQA4=f3oGzWzpDDjQAvWmW17nh9vHGOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 April 2016 at 21:43, Peter Geoghegan <pg(at)heroku(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2016-04-11 21:36:24 | Re: Remove unused function from walsender.c |
Previous Message | Julien Rouhaud | 2016-04-11 20:53:56 | Re: Choosing parallel_degree |