Page MenuHomePhabricator

[Regression] Installer: MySQL Fatal Error "1283: Column 'si_title' cannot be part of FULLTEXT index" for collation set to "binary"
Closed, ResolvedPublic

Description

$ php maintenance/install.php --dbname zetawiki --installdbuser root --installdbpass root --pass 1234 MyWiki Root

PHP 5.4.13 is installed.
Warning: Could not find APC, XCache or WinCache.
Object caching is not enabled.
Found GD graphics library built-in.
Image thumbnailing will be enabled if you enable uploads.
Using server name "http://localhost".
Warning: No --scriptpath specified, using default: /wiki.
Using server URL "http://localhost/wiki".
Warning: Your default directory for uploads (/Users/krinkle/Development/mediawiki/core/images/) is not checked for vulnerability
to arbitrary script execution during the CLI install.
Warning: The intl PECL extension is not available to handle Unicode normalization, falling back to slow pure-PHP implementation.
If you run a high-traffic site, you should read a little on Unicode normalization.
The environment has been checked.
You can install MediaWiki.
Setting up database
done
Creating tables
A database query syntax error has occurred.
The last attempted database query was:
"CREATE FULLTEXT INDEX si_title ON searchindex (si_title)
"
from within function "DatabaseBase::sourceFile( /Users/krinkle/Development/mediawiki/core/maintenance/tables.sql )".
Database returned error "1283: Column 'si_title' cannot be part of FULLTEXT index (localhost)"
Backtrace:
#0 /Users/krinkle/Development/mediawiki/core/includes/db/Database.php(986): DatabaseBase->reportQueryError('Column 'si_titl...', 1283, 'CREATE FULLTEXT...', 'DatabaseBase::s...', false)
#1 /Users/krinkle/Development/mediawiki/core/includes/db/Database.php(3421): DatabaseBase->query('CREATE FULLTEXT...', 'DatabaseBase::s...')
#2 /Users/krinkle/Development/mediawiki/core/includes/db/Database.php(3334): DatabaseBase->sourceStream(Resource id #90, false, false, 'DatabaseBase::s...', false)
#3 /Users/krinkle/Development/mediawiki/core/includes/installer/DatabaseInstaller.php(185): DatabaseBase->sourceFile('/Users/krinkle/...')
#4 [internal function]: DatabaseInstaller->createTables(Object(MysqlInstaller))
#5 /Users/krinkle/Development/mediawiki/core/includes/installer/Installer.php(1458): call_user_func(Array, Object(MysqlInstaller))
#6 /Users/krinkle/Development/mediawiki/core/includes/installer/CliInstaller.php(126): Installer->performInstallation(Array, Array)
#7 /Users/krinkle/Development/mediawiki/core/maintenance/install.php(119): CliInstaller->execute()
#8 /Users/krinkle/Development/mediawiki/core/maintenance/doMaintenance.php(110): CommandLineInstaller->execute()
#9 /Users/krinkle/Development/mediawiki/core/maintenance/install.php(133): require_once('/Users/krinkle/...')
#10 {main}


Version: 1.21.x
Severity: blocker

Details

Reference
bz47191

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.
bzimport set Reference to bz47191.
Krinkle created this task.Apr 13 2013, 5:58 AM

MySQL version 5.6.10 (latest stable).

MySQL database is newly created.

I cannot reproduce the problem with database collation set to binary.

However the default collation for new databases is utf8_general_ci (MySQL 5.6.10).

And when having that as the collation, I can reproduce this fatal error every time.

(In reply to comment #2)

MySQL database is newly created.

I cannot reproduce the problem with database collation set to binary.

However the default collation for new databases is utf8_general_ci (MySQL
5.6.10).

And when having that as the collation, I can reproduce this fatal error every
time.

Sorry, the other way around. On the default collation (utf8_general_ci) is works fine. When installing it on a newly created database with collation set to binary, it fails.

Possibly related issue:

  • Bug 48608 has been marked as a duplicate of this bug. ***

hexmode: Do you think you'll have some time to take a look at this problem?

Ied512a75 *might* fix this, though I have not tested or reviewed it, only
tweaked the commit message.

I will test this fix later today.

(In reply to comment #8 by Mark A. Hershberger)

I will test this fix later today.

hexmode: Any news?

(In reply to comment #8 by Mark A. Hershberger)

I will test this fix later today.

hexmode: Any news?

Change 86075 had a related patch set uploaded by PleaseStand:
Use utf8 charset for searchindex MySQL table

https://gerrit.wikimedia.org/r/86075

Change 86075 merged by jenkins-bot:
Use utf8 charset for searchindex MySQL table

https://gerrit.wikimedia.org/r/86075

Should be fixed by 2f02c77b4ef1d6a7d6a8e8862ead5592863d7988. Existing and new databases having a "binary" character set should no longer be a problem.

Do users experience this problem frequently enough to warrant backporting the one-line patch to older versions of MediaWiki?

Also, why was the severity set to "blocker", if this had an easy workaround
(don't do CREATE DATABASE ... CHARACTER SET binary)? Just because a developer
experienced this?

(In reply to comment #13)

Also, why was the severity set to "blocker", if this had an easy workaround
(don't do CREATE DATABASE ... CHARACTER SET binary)? Just because a developer
experienced this?

If a user came across this, it would block their upgrade/installation.