Bug #57229 not clear if 'profiling' and 'have_profiling ' variables are synonyms in 5.5
Submitted: 4 Oct 2010 21:27 Modified: 16 Oct 2012 5:24
Reporter: Peter Laursen (Basic Quality Contributor) Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Options Severity:S3 (Non-critical)
Version:5.5.6, 5.5.7-bzr OS:Any
Assigned to: CPU Architecture:Any
Tags: qc, regression

[4 Oct 2010 21:27] Peter Laursen
This is a follow-up on an earlier report: http://bugs.mysql.com/bug.php?id=48344

The original report dealed with an inconsistency between 5.0 and 5.1 servers. I added a few comments regarding 5.5 a few days ago.  They read (with a few clarifications): 


There is a regression in 5.5!

SELECT VERSION(); -- 5.5.6-rc

Variable_name           Value 
----------------------  ------
have_profiling          YES   
profiling               OFF   
profiling_history_size  15    

SELECT VERSION(); -- 5.1.51-community

Variable_name           Value 
----------------------  ------
profiling               OFF   
profiling_history_size  15       

So what now?

OK .. documentation at 
.. lists both (unlike what http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html did)


YES if statement profiling is enabled, NO if not. See Section, “SHOW PROFILE Syntax”.


If set to 0 (the default), statement profiling is disabled. If set to 1, statement profiling is enabled and the SHOW PROFILES and SHOW PROFILE statements provide access to profiling information. See Section, “SHOW PROFILES Syntax”.

If MySQL wants to keep both for some backwards compatibility reason I have no issues. But

1) they must then be *complete synonyms*?  I so docs should state this. And if they are not *complete synonyms* docs should explain the difference.
2) one is described using 0|1 parameters (even though SHOW returns ON|OFF) and the other using YES|NO parameters and they refer section and section respectively what is a minor inconsistency in docs.

It has always been somewhat unclear to me if comments to old reports (also to *verified* reports) are read or not.  I mostly have the impression that they are not.  

If you want to mark as 'duplicate' I have no issue - if only the main scope of this discussion now focus'es on clarifying the meaning of both variables in 5.5.  But probably marking the old one as 'wont fix' (as 5.0 is out of support) and this one as 'verified' seems to me to be the better solution.

Experiments tell me that 'profiling' decides (alone) whether the server supports PROFILING. The 'query profile' feature of (our) SQLyog ULTIMATE program only considers 'profiling' variable (and not 'have _profiling' at all) and works as expected with 5.5x.

How to repeat:
see above

Suggested fix:
see above
[4 Oct 2010 21:28] Peter Laursen
fixed typo in synopsis.
[4 Oct 2010 21:32] Peter Laursen
.. or maybe rather 'have_profiling' is completely redundant and not used at all?
[5 Oct 2010 7:50] Valeriy Kravchuk
Indeed, this is strange to have have_profiling back in 5.5. I do not think it is needed.
[12 Jan 2011 9:49] Georgi Kodinov
have_profiling is redundant, leads to no action and needs to go. Probably just a bad merge.
[16 Oct 2012 5:24] Erlend Dahl
Analysis by the dev team:

have_profiling is a *read-only* variable that shows whether the profiling
code is present in MySQL or not.

"profiling" is a *read-write* variable that controls whether profiling
information is actually collected or not.

So they're not the same thing (despite the similarly sounding names).

Hence closing as "not a bug".