Last modified: 2010-03-16 18:52:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9350 - update.php -> SQL error
update.php -> SQL error
Status: RESOLVED DUPLICATE of bug 4445
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.10.x
PC Linux
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-20 12:46 UTC by Purodha Blissenbach
Modified: 2010-03-16 18:52 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Purodha Blissenbach 2007-03-20 12:46:17 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
Comment 1 Greg Sabino Mullane 2007-03-20 13:36:06 UTC
Looks like a variation of bug #1322, although it seems unlikely that pr_id alone
would cause it.
Comment 2 Purodha Blissenbach 2007-03-20 14:11:39 UTC
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.
Comment 3 Purodha Blissenbach 2007-03-20 14:33:17 UTC
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.
Comment 4 Tim Starling 2007-09-24 01:01:28 UTC
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. 
Comment 5 Brion Vibber 2007-09-24 15:02:05 UTC
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
Comment 6 Aaron Schulz 2007-09-24 15:28:19 UTC
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).
Comment 7 Chad H. 2010-03-16 18:52:58 UTC

*** This bug has been marked as a duplicate of bug 4445 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links