Last modified: 2010-07-09 21:21:12 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 4183 - 1.4.12 -> 1.5.2 or 1.5.3 update failing with MySQL error Duplicate entry '5-1' for key 1
1.4.12 -> 1.5.2 or 1.5.3 update failing with MySQL error Duplicate entry '5-1...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.5.x
Other Linux
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-05 17:21 UTC by David Biesack
Modified: 2010-07-09 21:21 UTC (History)
1 user (show)

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


Attachments

Description David Biesack 2005-12-05 17:21:02 UTC
I am getting a failure trying to upgrade from 1.4.12 to either 1.5.2 or 1.5.3. I
have problems running update.php :

   from update.php:

   ...converting from cur/old to page/revision/text DB structure.
   1133553182......checking for duplicate entries.
   1133553182......Creating tables.
   1133553182......Locking tables.
   1133553182......maxold is 6155
   1133553182......Moving text from cur.
   1133553182......Setting up revision table.
   1133553182......Setting up page table.
   1133553182......Unlocking tables.
   1133553182......Renaming old.
   1133553182...done.
   revision timestamp indexes already up to 2005-03-13
   Adding rev_text_id field... Query "UPDATE revision SET rev_text_id=rev_id"
failed with error code "".

Note that my page and revision tables exist at this point but both are empty:

    mysql> show tables;
    +--------------------------+
    | Tables_in_saspediadb_dev |
    +--------------------------+
    | archive                  |
    | blobs                    |
    | brokenlinks              |
    | categorylinks            |
    | cur                      |
    | hitcounter               |
    | image                    |
    | imagelinks               |
    | interwiki                |
    | ipblocks                 |
    | links                    |
    | linkscc                  |
    | logging                  |
    | math                     |
    | objectcache              |
    | oldimage                 |
    | page                     |
    | querycache               |
    | recentchanges            |
    | revision                 |
    | searchindex              |
    | site_stats               |
    | text                     |
    | trackbacks               |
    | transcache               |
    | user                     |
    | user_newtalk             |
    | user_rights              |
    | validate                 |
    | watchlist                |
    +--------------------------+
    30 rows in set (0.00 sec)

    mysql> select * from page;
    Empty set (0.00 sec)

    mysql> select * from revision;
    Empty set (0.00 sec)

I have narrowed this down to execution of the following query from updaters.inc
near line 390:

        $wgDatabase->query( "INSERT INTO $revision (rev_id, rev_page,
rev_comment, rev_user, rev_user_text, rev_timestamp,
                                rev_minor_edit)
                        SELECT old_id, cur_id, old_comment, old_user, old_user_text,
                                old_timestamp, old_minor_edit
                        FROM $old,$cur WHERE old_namespace=cur_namespace AND
old_title=cur_title",  $fname );

If I run this query directly via mysql

INSERT INTO revision (rev_id, rev_page, rev_comment, rev_user, rev_user_text,
rev_timestamp,
                                rev_minor_edit)
                        SELECT old_id, cur_id, old_comment, old_user, old_user_text,
                                old_timestamp, old_minor_edit
                        FROM old,cur WHERE old_namespace=cur_namespace AND
old_title=cur_title;

I get the following error:

  ERROR 1062 (23000): Duplicate entry '5-1' for key 1

Note: If I try to run upgrade1_5.php (on a clean reinstall, before running
update.php), I get a different error:

2005-12-05 17:13:42: Checking cur table for unique title index and applying if
necessary
saspediadb_dev: cur table has the old non-unique index and may have duplicate
entries.
Checking for duplicate cur table entries... (this may take a while on a large wiki)
Found 0 titles with duplicate entries.
Done.
2005-12-05 17:13:42: ...converting from cur/old to page/revision/text DB structure.
2005-12-05 17:13:42: Creating page and revision tables...
2005-12-05 17:13:42: Last old record is 6156
......Moving text from cur.
2005-12-05 17:13:42: Last cur entry is 2147
2005-12-05 17:13:42:      4.66% done on old; ETA 2005-12-05 17:13:47 [100/2147]
439.74/sec
2005-12-05 17:13:42: 100.00% done on old (last chunk 0 rows).
Unable to free MySQL result

The conversion from text to cur aborts after the first chunk.

Because of these errors, I am stuck and unable to upgrade from 1.4.2 to 1.5.x

We're running (Special:Version) :

    MediaWiki (http://wikipedia.sf.net/): 1.4.12 
    PHP (http://www.php.net/): 4.4.1 (apache) 
    MySQL (http://www.mysql.com/): 4.1.7-standard-log

here is what update.php showed before trying to convert the tables:

   # php update.php
   X-Powered-By: PHP/4.1.2
   Content-type: text/html

   Going to run database updates for saspediadb_dev
   Depending on the size of your database this may take a while!
   Abort with control-c in the next five seconds... 5 4 3 2 1 0
   ...hitcounter table already exists.
   ...querycache table already exists.
   ...objectcache table already exists.
   ...categorylinks table already exists.
   ...logging table already exists.
   Creating validate table...ok
   ...user_newtalk table already exists.
   Creating transcache table...ok
   Creating trackbacks table...ok
   ...have ipb_id field in ipblocks table.
   ...have ipb_expiry field in ipblocks table.
   ...have rc_type field in recentchanges table.
   ...have rc_ip field in recentchanges table.
   ...have rc_id field in recentchanges table.
   ...have rc_patrolled field in recentchanges table.
   ...have user_real_name field in user table.
   ...have user_token field in user table.
   Adding user_email_token field to table user...ok
   ...have log_params field in logging table.
   Adding ar_rev_id field to table archive...ok
   Adding ar_text_id field to table archive...ok
   ...page table does not exist, skipping new field patch
   ...revision table does not exist, skipping new field patch
   Adding img_width field to table image...ok
   Adding img_metadata field to table image...ok
   Adding img_media_type field to table image...ok
   ...have val_ip field in validate table.
   ...have ss_total_pages field in site_stats table.
   Adding iw_trans field to table interwiki...ok
   ...already have interwiki table
   ...indexes seem up to 20031107 standards
   Converting links table to ID-ID...
   Schema already converted
   ...image primary key already set.
   The watchlist table is already set up for email notification.
   User table contains old email authentication field. Dropping... ok
   Logging table has correct title encoding.
Comment 1 Brion Vibber 2007-01-17 13:08:29 UTC
Poking through the old updaters...

I really don't see how this would be possible unless the cur and old tables were
really horribly borked, like with duplicate values in the old_id and cur_id
fields (or else 'revision' not actually being empty). Even as of 1.2, the tables
had unique indexes on the id fields so that shouldn't be possible.

Can confirm that dupe cur rows don't seem to be a problem as they get caught.

If anyone still encounters this, I'd appreciate getting hold of a database dump
to test with.
Comment 2 Chad H. 2010-07-09 21:21:12 UTC
Closing WFM per Brion's comment back in '07. He couldn't replicate it then and I'd expect the situation to be the same now.

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


Navigation
Links