MySQL Bugs: #72019: Is my server 32 bit or 64 bit?

Bug #72019	Is my server 32 bit or 64 bit?
Submitted:	12 Mar 2014 12:13	Modified:	31 Mar 2014 13:38
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	any	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
I was asked by a user "How do I know if the server I am connected to is 32 bit or 64 bit server?".

I find the server variable "version_compile_os" explained in http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_version_compile... as "The type of operating system on which MySQL was built."

Now - you can build 32 bit software on 64 bit OS using 64 bit compilers (that is true for Windows/Visual Studio at least). Cross-compilers (that may compile *ON* one platform *FOR* another) also exist where it really does not matter much *ON* what OS it was built.

So if "SHOW VARIABLES LIKE 'version_compile_os';" returns (for instance) "Win64", does this guarantee that the server connected to is a 64 bit server?

How to repeat:
See above.

Suggested fix:
1)
if "SHOW VARIABLES LIKE 'version_compile_os';" returning (for instance) "Win64", means that the server is a 64 bit server, I find the phrasing in documentation slightly incorrect. In that case it is not *ON* what OS but *FOR* what OS it is compiled that matters.

2)
if "SHOW VARIABLES LIKE 'version_compile_os';" returning (for instance) "Win64", means that the server can be either a 32 bit or a 64 bit server (but was built on a 64 bit OS), I am missing an option to decide what it actually is (except that in some cases very large settings for various buffers that can be shown by executing SHOW VARIABLEs would exclude 32 bit)

It is sometimes relevant for client users to know this, even if they have no stake in installing/administering/managing the server and have no other acccess to such information than what SHWO VARIABLES expose.

I have used the category "options" for this report. But if 1) above is the case then rather it should be "deocumentation", probably.

I tried on a local Win64 bit 5.6.15 server. Here version_compile_os is "Win64". 

However a Linux 5.6.12 server (official MySQL/Oracle server binary) that I have access to only returns "Linux" for this variable.

Thank you for the bug report. As workaround:

On Linux use the file tool:

[miguel@TikalVM 5.6]$ file bin/mysqld
bin/mysqld: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

On Windows look in the Process tab of Task Manager:

 If there is a *32 suffix after the process name (i.e: mysql client), it's 32-bit, otherwise it's 64-bit (assuming you are on Windows 64-bits OS).

I found a trick!  You may try to set the SESSION variable for one variabel that has different range on 32 bit and 64 bit systems - such as 

SET SESSION bulk_insert_buffer_size = 429496726;
SHOW VARIABLES LIKE 'bulk_insert_buffer_size';

.. what is returned?  If the server is 32 bit it will be 'rounded down' to '429496725', I think (or first statement may result in an error or a warning - and don't forget to SET the variable back to a reasonable value).

But I think that it is a resonable request to ask for more info about both build and runtime environment exposed as variables. This is the only way users can know the ranges for certain variables, for instance. 

On Linux the commands "uname -a" and "cat /etc/issue" are commonly used to expose the environment - and such details could be included.  Also compiler, version of same and version of C-runtime version could be exposed (GCC and GLIBC on Linux typically). And 'cross-compilation' details (such as when a 32 bit version is built on a 64 bit platform)

@Miguel.  please stop thinking about "file tools" and similar. The cleint API and protocol does not provide access to file system for a MySQL client.

We are talking about a situation where a user has *ONLY* access to MySQL on a remote server, and he has *nothing else to do* with and *no other kind of access to* this server. What he knows is the hostname/ip, the MySQL port, his username and password (and maybe SSL and/or SSH details) - and *nothing else at all*.

What about http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_version_compile...:

"The type of the server binary."

This is 64-bit binary:

mysql> show variables like 'version%';
+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| version                 | 5.6.16-log                   |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | Win64                        |
+-------------------------+------------------------------+
4 rows in set (0.59 sec)

because of the "version_compile_machine". Do I miss anything?

Also these may work:

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysql --version
mysql  Ver 14.14 Distrib 5.6.16, for Win64 (x86_64)

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysqld --version
mysqld  Ver 5.6.16 for Win64 on x86_64 (MySQL Community Server (GPL))

from server side.

@Valeriy ..

1) 
I cannot clearly read this in documentation. The word "type" in the phrase "The type of the server binary" is unclear to me. What exactly is covered by the term "type"? It should be more clear IMO. In particular as the variable name itself isn't particularly clear. If "type" means "CPU architecture" then write that!

2)
I am talking about situations where user does not have access to run commands from a shell on the server machine (or SSH into it, TELNET into it etc.).  I could then also request that "SELECT VERSION()" from a client would return the same amount of information as what "mysqld -v" from a shell does.

As I worte in my first post, I was uncertain if the category for this was "options" or "documentation".

Peter,

You wrote: Bug #72019 	Is my server 32 bit or 64 bit?

So I assumed is your server on your machine now you are talking about remote
user?. Anyway the bug is on Verified status.

OK - let me clarify! :-)

When I wrote "my server" I simply meant "a server I have access to use". This includes the situation where the only access I have is a connection from a client.
(and with "me"/"I", I did not mean me pesonally, but any MySQL (client) user).

If Valeriy's understanding is correct (ie. if 'version_compile_machine' exposes the architecture that the server was compiled *FOR* - and has nothing to do with *ON* what architecture it was built), I think docs could be clearer about that. It makes sense if it is like that, but without Valeriy's explanation I was not able to understand it such.

Peter,

I assumed you wanted to read when connecting or issuing the show variables like "version" i.e.: executable binary: X86_64 bit. If the Valeriy comment is enough
for you then the bug could be closed or making it as doc bug.

Thanks.

MTR testsuite has to answer the same question too and apparently it uses the same trick with different variable ranges:

5.7.3 mysql-test/include/have_32bit.inc:

# Created by Horst Hunger     2008-04-15
# see also have_64bit.inc

--disable_query_log
--disable_warnings
let $save = `SELECT @@global.myisam_sort_buffer_size`;
SET @@global.myisam_sort_buffer_size = 4294967296;
let $mach32 = `SELECT @@global.myisam_sort_buffer_size <= 4294967295`;
eval SET @@global.myisam_sort_buffer_size = $save;
--enable_warnings
--enable_query_log
if (!$mach32)
{
  skip Need a 32 bit machine/binary;
}

5.7.3 mysql-test/include/have_64bit.inc:

# Created by Horst Hunger       2008-04-15
# see also have_32bit.inc

--disable_query_log
let $save = `SELECT @@session.sort_buffer_size`;
SET @@session.sort_buffer_size = 4294967296;
let $mach64 = `SELECT @@session.sort_buffer_size > 4294967295`;
eval SET @@session.sort_buffer_size = $save;
--enable_query_log
if (!$mach64)
{
  skip Need a 64 binary ;
}

Why should an SQL user need to know what "bitness" the mysqld binary is anyway?
What is the practical reason to know?

Posted by developer:
 
On windows, we do this:

IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
  SET(SYSTEM_TYPE "Win64")
  SET(MYSQL_MACHINE_TYPE "x86_64")
ELSE()
  SET(SYSTEM_TYPE "Win32")
ENDIF()

This is used in
config.h.cmake:#define SYSTEM_TYPE "@SYSTEM_TYPE@" 
And SYSTEM_TYPE is used for version_compile_os

version_compile_machine is based on MACHINE_TYPE

For Darwin, we do
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
  SET(MYSQL_MACHINE_TYPE "x86_64")
ENDIF()

Similarly for Solaris on intel.

The trick with 
SET SESSION bulk_insert_buffer_size = 429496726;
can be used on platforms where sizeof(long) == sizeof(longlong)
i.e. it cannot be used on windows, since the variable has type ulong,
which is still only four bytes, even in a 64bit environment.

So, yes, it is possible to find out "is my server 32bit or 64bit"
but it is not straightforward.

Reply to @Shane. Because this is the only way to know in advance the possible range of a large number of variables.

As my final conclusion here I would suggest taht the explanation in docs as regards version_compile_machine and version_compile_os variables is elaborated (what values they can have and what can actually be (and cannot be) decided/concluded from their values.