ourdelta-developers team mailing list archive

[Arjen Lentz <arjen@xxxxxxxxxxxxx>]

Hi Vadim

On 29/07/2009, at 5:45 PM, Vadim Tkachenko wrote:
> I removed CLIENT_STATISTICS from 5.0.84 patches

Why? There's a fix for this one.
See https://code.launchpad.net/~d-launchpad-askneil-com/ourdelta/ 
ourdelta-fix-bug338012
Was attached to the bugreport.

There are actually specific requests to port the *_STATISTICS features  
to 5.1
Let's process the bugreports and contributed fixes, rather than  
ripping it out?
Thanks

Cheers,
Arjen.
-- 
Arjen Lentz, Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org




** Also affects: percona-patches
   Importance: Undecided
       Status: New

-- 
CLIENT_STATISTICS are broken if hostname is > 16 chars
https://bugs.launchpad.net/bugs/338012
You received this bug notification because you are a member of OurDelta-
developers, which is the registrant for OurDelta.

Status in OurDelta - Builds for MySQL: Fix Committed
Status in Patches for MySQL by Percona: New

Bug description:

I noticed today that the CLIENT_STATISTICS tables were not working properly if the hostnames are longer
than 16 characters.  I am running these packages from the ourdelta repository (centos5.2):

MySQL-OurDelta-client.x86_64             5.0.67.d7-44.el5_2     installed
MySQL-OurDelta-server.x86_64             5.0.67.d7-44.el5_2     installed
MySQL-OurDelta-shared.x86_64             5.0.67.d7-44.el5_2     installed

mysql> select count(*) from client_statistics;
+----------+
| count(*) |
+----------+
|  1485697 |
+----------+
1 row in set (1.62 sec)

mysql> select client from client_statistics limit 20;
+------------------+
| client           |
+------------------+
| gonzo17i.bunchba |
|                  |
| gonzo23i.bunchba |
| gonzo20i.bunchba |
| gonzo20i.bunchba |
| gonzo23i.bunchba |
| gonzo20i.bunchba |
| gonzo20i.bunchba |
| gonzo17i.bunchba |
| gonzo17i.bunchba |
| gonzo20i.bunchba |
| gonzo23i.bunchba |
| gonzo20i.bunchba |
| gonzo17i.bunchba |
| gonzo23i.bunchba |
| gonzo20i.bunchba |
| gonzo17i.bunchba |
| gonzo20i.bunchba |
| gonzo15i.bunchba |
| gonzo17i.bunchba |
+------------------+
20 rows in set (1.36 sec)


As you can see, there are lots of duplicate rows.  The heart of the problem seems to be this
code from the google patch:

ourdelta-mybranch/mysql/5.0/google/userstatsv2/userstatsv2-main.patch.

Client name lengths are set to LIST_PROCESS_HOST_LEN (64), but the CLIENT column is set to 16 characters.
This means that there will be rows in client stats table that will be distinct, but indistinguishable in the show client_statistics output.  The CLIENT column should probably have the same length (its set in this line:

+  {"CLIENT", 16, MYSQL_TYPE_STRING, 0, 0, "Client"},

But the underlying problem seems to be in a different place.

There is a routine to initialize the statistics:

+void init_global_client_stats(void)
+{
+  if (hash_init(&global_client_stats, system_charset_info, max_connections,
+                0, 0, (hash_get_key)get_key_user_stats,
+                (hash_free_key)free_user_stats, 0)) {
+    sql_print_error("Initializing global_client_stats failed.");
+    exit(1);
+  }
+}

The get_key_user_stats is shared between the global_user_stats and global_client_stats hash tables.
Here is the definition of that function:

+byte *get_key_user_stats(USER_STATS *user_stats, uint *length,
+                         my_bool not_used __attribute__((unused)))
+{
+  *length = strlen(user_stats->user);
+  return (byte*)user_stats->user;
+}

The "user_name" field is being shared between user and client statistics.  This field is limited to 16 characters.  But when a hash match is being looked for, we are comparing against a 64 char host name, and we are always inserting a new row.