Bug #32689 mysql_upgrade fails with the message FATAL ERROR: mysqlT 'N' NOT NULL;
Submitted: 24 Nov 2007 0:39 Modified: 28 Nov 2007 7:02
Reporter: Anatoly Pidruchny (Candidate Quality Contributor) Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version:5.1.22 OS:HP/UX (11.11)
Assigned to: CPU Architecture:Any
Tags: qc

[24 Nov 2007 0:39] Anatoly Pidruchny
Description:
When I am running mysql_upgrade on an HP-UX platform, I am getting the error message. mysql_upgrade worked fine on a Linux platform that I tried. I also tried to run mysqlcheck and mysql_fix_privilege_tables scripts directly on HP-UX platform and they seemed to worked just fine. So, it must be a problem with mysql_upgrade tool itself. Below is the output:

$ mysql_upgrade
Looking for 'mysql' in: mysql
FATAL ERROR: mysqlT 'N' NOT NULL;
 
 ALTER TABLE db ADD Trigger_priv enum('N','Y') COLLATE utf8_general_ci DEFAULT 'N' NOT NULL;
 ALTER TABLE db MODIFY Trigger_priv enum('N','Y') COLLATE utf8_general_ci DEFAULT 'N' NOT NULL;
 
 ALTER TABLE tables_priv MODIFY Table_priv set('Select','Insert','Update','Delete','Create','Drop','Grant','References','Index','Alter','Create View','Show view','Trigger') COLLATE utf8_general_ci DEFAULT '' NOT NULL;
 
 UPDATE user SET Trigger_priv=Super_priv WHERE @hadTriggerPriv = 0;
 
 # Activate the new, possible modified privilege tables
 # This should not be needed, but gives us some extra testing that the above
 # changes was correct
 
 flush privileges;

How to repeat:
Just install MySQL 5.1.22 and run mysql_upgrade on HP-UX 11.11.
[24 Nov 2007 9:37] Hartmut Holzgraefe
Which version do you try to upgrade from?
[24 Nov 2007 20:20] Anatoly Pidruchny
Hartmut,

I first tried to upgrade from 5.1.20. But I do not think it matters. I then just re-created the initial databases (mysql, information_schema and test) with mysql_install_db and created our database manually with "CREATE DATABASE" statement. Then all the tables in the database were discovered from the NDB data nodes. Then I just tried to run mysql_upgrade again and I got the same error message.

/Anatoly.
[25 Nov 2007 6:55] Sveta Smirnova
Thank you for the feedback.

Please indicate accurate version of package you use (file name).
[25 Nov 2007 20:09] Anatoly Pidruchny
Sveta,

I did some more testing. I was using the source distribution of MySQL (file name mysql-5.1.22-rc.tar.gz). What I found out is that mysql_upgrade works fine if I run it from the bin sub-directory! I did not find anywhere in the documentation that it is necessary to cd to the /usr/local/mysql/bin directory before running mysql_upgrade. If I run mysql_upgrade from any other directory then I am getting the error message reported.

I also tried the binary distribution. I installed MySQL software using the file mysql-5.1.22-rc-hpux11.11-hppa2.0w.tar.gz. As with the source distribution, mysql_upgrade works fine if the current directory is the bin sub-directory. If mysql_upgrade is started from any other directory, another error is reported:

$ mysql_upgrade --datadir=/sm/mysql/mysqld_data --verbose
Looking for 'mysql' in: mysql
FATAL ERROR: Can't find 'mysql'

At least this error message is better. I think it is still not good that mysql_upgrade must be run from the bin sub-directory. And, of course, the error message produced by the source distribution is not good at all.

I also re-tested mysql_upgrade on Linux. I did not find any problems with mysql_upgrade on Linux. I could run it from any directory and it worked just fine.

/Anatoly.
[26 Nov 2007 21:36] Sveta Smirnova
Thank you for the feedback.

Error

> Looking for 'mysql' in: mysql
> FATAL ERROR: Can't find 'mysql'

is duplicate of bug #31605.

To find if original description is new bug, please, provide your configure options.
[27 Nov 2007 6:49] Anatoly Pidruchny
Sveta,

I just did some more investigation. Yes, the error happens definitely because of bug #31605. It was just interesting why the funny error message was printed. I came to conclusion that it was most probably because of my compiler optimization bug. Just adding a printf() call into the find_tool() function in mysql_upgrade.c made the compiler generate correct code and the expected error message "FATAL ERROR: Can't find 'mysql'" was printed.

I think you can close this bug report as duplicate of bug #31605.

Just in case, here is what compiler I use:

$ aCC -V
aCC: HP ANSI C++ B3910B A.03.56

The configure line:

./configure '--prefix=/usr/local/mysql' '--localstatedir=/usr/local/mysql/data' '--libexecdir=/usr/local/mysql/bin' '--with-comment=MySQL Community Server (GPL)' '--with-server-suffix=' '--enable-thread-safe-client' '--enable-local-infile' '--with-pic' '--disable-shared' '--with-client-ldflags=-static' '--with-mysqld-ldflags=-static' '--with-zlib-dir=bundled' '--with-big-tables' '--with-readline' '--with-embedded-server' '--with-archive-storage-engine' '--with-blackhole-storage-engine' '--with-ndbcluster' '--with-csv-storage-engine' '--with-example-storage-engine' '--with-federated-storage-engine' '--with-partition' '--with-innodb' '--with-extra-charsets=all' 'CC=cc' 'CFLAGS=+O2 +DA2.0N +Z +ESnolit' 'CPPFLAGS=-DDEFAULT_THREAD_STACK=262144' 'CXXFLAGS=+O2 +DA2.0N +Z +ESnolit -Aa' 'CXX=aCC'

Thanks,
/Anatoly.
[28 Nov 2007 7:02] Sveta Smirnova
Thank you for the feedback.

Marked as duplicate of bug #31605.