Bug #39790 There is no way to determine the source of many configuration options values
Submitted: 1 Oct 2008 20:33 Modified: 3 Oct 2008 4:35
Reporter: Shawn Green Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: General Severity:S4 (Feature request)
Version:any OS:Any
Assigned to: CPU Architecture:Any

[1 Oct 2008 20:33] Shawn Green
The SHOW [GLOBAL|SESSION] VARIABLES report only shows the current value for each setting/variable it exposes. What is necessary, in some cases of problem diagnosis, is an additional column of information. 

This additional column of information will document the source of the current value. 

* If the source was a config file, this column would contain the full path to that file. 

* If the source was a command line option, it would contain the string "command line"

* If the most recent value to this setting/variable came from a user, then this third column would contain the full user@hostname id of the user and a timestamp of when it was last set. 

How to repeat:

Suggested fix:
Add a the requested information to the variables and expose the metadata in the SHOW VARIABLES report.
[3 Oct 2008 4:35] Valeriy Kravchuk
Thank you for a reasonable feature request.
[19 Apr 2013 13:19] MySQL Verification Team
To preserve reverse compatibility, the normal SHOW VARIABLES reports should be maintained. The extra column of source-related information should only appear if we include some extra keyword like EXTENDED.

[19 Apr 2013 14:09] Craig Sylvester
This is an excellent suggestion. I always thought MySQL should at least document which configuration file(s) were used to start the server. But your suggestion is much better.
[23 Apr 2014 20:52] Stephen Werner
It would be great to know when a parameter was changed.  numerous database servers have this as a standard, will at least it is logged to the server log or in Sybase case the configuration file is backed up first sybase.001 from sybase.cfg.  Would be a difficult one logging the host though unless the system is locked (no access to the db_server from the localhost).  Then again I have heard hostnames can be alias via Java.

Anyway, if the parameter had a time_of_change, current_setting, old_setting and have this logged to the server.log, updated in the config (and roll the config file) as will as table entry.

Possibly have an audit trigger (optional, as some overnight processing may use different parameter settings) to log an audit table configuration changes etc..

My 5 cent rant. (possibly more to come..)