On Mon, Apr 11, 2016 at 4:43 PM, Peter Geoghegan <p...@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.
I'm not excited about this change. It doesn't really buy us anything that I can see. For one thing, I think we've arguably got too much trace_sort output from sorts now and should look to reduce that instead of further normalizing it. For another thing, the only advantage to removing it is that it makes it easier to add even more, and we're not going to do that in 9.6. If we decide to do it in 9.7, we can consider the proposal to remove TRACE_SORT calls then. There is just nothing urgent about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
