Last modified: 2010-03-16 18:52:58 UTC
Updated to revision 20562. Then starteed ./maintenance/pudate.php which terminated with: ...have rev_parent_id field in revision table. Adding pr_id field to table page_restrictions...Query "ALTER TABLE `page_restrictions` ADD COLUMN pr_id int unsigned not null auto_increment, ADD UNIQUE KEY pr_id (pr_id) " failed with error code "Specified key was too long. Max key length is 500 (localhost)". Special:Versions says: MediaWiki: 1.10alpha PHP: 5.0.5 (cgi) MySQL: 4.0.24_Debian-10sarge2-log
Looks like a variation of bug #1322, although it seems unlikely that pr_id alone would cause it.
As far as I remember, adding an "auto_increment" field automatically creates an index on it, so for a test I altered the script ./maintenance/archives/patch-page_restrictions_sortkey.sql which contains: ---cut---cut---cut--- -- -- Add a sort-key to page_restrictions table. -- First immediate use of this is as a sort-key for coming modifications -- of Special:Protectedpages. -- Andrew Garrett, February 2007 ALTER TABLE /*$wgDBprefix*/page_restrictions ADD COLUMN pr_id int unsigned not null auto_increment, ADD UNIQUE KEY pr_id (pr_id(10)); ---cut---cut---cut--- by omitting the "ADD UNIQUE KEY" clause, and rerun ./maintenance/ update.php Indeed, the result is exactly the same as before.
An inspection of the `page_restrictions` table reveals an oddity: there is a PRIMARY INDEX on (`pr_page`, `pr_page`) while at the same time there is an INDEX on (`pr_page`) imho does not make sense. Since there was no data in the `page_restrictions` table, I wanted to drop the PRIMARY INDEX, rerun the script, and later recreate it with a reduced sice: ALTER TABLE `page_restrictions` DROP PRIMARY KEY; #1071 - Specified key was too long. Max key length is 500 pr_page: pr_page(8) pr_type: varchar(255) This leads me to the assumption that, just before, the size of `pr_type` might have been increased. ALTER TABLE `page_restrictions` CHANGE `pr_type` `pr_type` VARCHAR( 48 ) NOT NULL; Next ran ./maintenance/update.php withe the original ./maintenance/archives/patch-page_restrictions_sortkey.sql with success. So a fix should possible obtain the maximum key length from the server, and if need be, reduce either the field size, or the part of the field going into the index, accordingly.
Can you please explain how you managed to get a maximum key length of 500? I've only seen maximums of 1000 and 1024 before, so the schema was adjusted to work for 1000, with 3 bytes per character.
The maximum key length was apparently 500 on MyISAM prior to 4.1.2. http://dev.mysql.com/doc/refman/4.1/en/myisam-storage-engine.html
Note that pr_type should be varchar(64). This was changed and backported to 1.10 as well. Some installations have it as 255 (by local test site has it too).
*** This bug has been marked as a duplicate of bug 4445 ***
