MySQL Bugs: #39790: There is no way to determine the source of many configuration options values

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:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	any	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
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:
n/a

Suggested fix:
Add a the requested information to the variables and expose the metadata in the SHOW VARIABLES report.

Thank you for a reasonable feature request.

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.

SHOW [GLOBAL|SESSION] VARIABLES[ EXTENDED][ LIKE ... ]

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.

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