MySQL Bugs: #23728: --skip-name-resolve is not a variable

Bug #23728	--skip-name-resolve is not a variable
Submitted:	27 Oct 2006 16:31	Modified:	23 Nov 2006 12:07
Reporter:	John David Duncan	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.0, 5.1	OS:	Any (All)
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
It is possible to start mysqld with the --skip-name-resolve option.

However there is not a corresponding variable, so there is no way to query a running server and see whether it is running with this option. 

This means, for instance, that when a person runs "show variables" and sends the results to a mysql consultant, they might be running with --skip-name-resolve, but the consultant would never know that.  

How to repeat:
mysqld --skip-name-resolve

SHOW VARIABLES;

Suggested fix:
Create a server variable to correspond to the option.

Thank you for the bug report.

Marlked as duplicate of Bug#23606

Is this going to be address I need to verify that we are not using reverse dns on some of our env.

I think you can connect to the server and check with "show processlist" what it's says in the Host column.

Still open after 2 years? The server variables in mysqld.cc need to be refactored. This would be much less error prone if there were 1 way to declare them that descrbed how to parse them and how to display them. Today, mysqld.cc is modified for parsing them and then set_var.cc is edited to add support for displaying them. And why is this declared with a 'skip-' prefix? I thought that was supported for any boolean variable that didn't require an argument. It is lovely that some system variables modify values in C variables, while others such as 'skip-name-resolve' don't and rely on get_one_option. This code is a mess. That was fine a few years back.

Plus one from me.

Has this bug been fixed? I am experiencing painfully slow connect times to some remote mysql servers.

Another +1 from me.  This would be very helpful.