Last modified: 2008-04-15 18:46: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 13745 - redirect table key violation
redirect table key violation
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Roan Kattouw
Depends on:
  Show dependency treegraph
Reported: 2008-04-15 02:35 UTC by aaron brick
Modified: 2008-04-15 18:46 UTC (History)
3 users (show)

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


Description aaron brick 2008-04-15 02:35:00 UTC
r33133 certainly fixed the previous redirect problem but it appears to have enabled this error to occur:

internal_api_error_DBQueryError, Exception Caught: A database error has occurred
Query: INSERT  INTO `redirect` (rd_from,rd_namespace,rd_title) VALUES ('57666','0','Vientiane')
Function: Database::insert
Error: 1062 Duplicate entry '57666' for key 1 (
, for "Vientiane, Laos"!
Comment 1 Roan Kattouw 2008-04-15 13:49:06 UTC
Is that error reproducible? I strongly suspect that's a race condition. I, for one, can't reproduce this at,_Laos&redirects Marking as WONTFIX, please REOPEN if you get this error message more frequently.

What probably happened here is that two people ran the above query more or less simultaneously, and that query 1 inserted a row into the redirect table *after* query 2 had discovered the row wasn't there. When query 2 (you) tries to add a row that's already there, it dies. This condition is very rare, however (two people querying an ancient redirect that hasn't been queried before at the same time), so I'll just mark this as WONTFIX. The odds of this error occurring again after today (r33133 went live today) are astronomical, since it can only occur once for every ancient redirect, and only if the first query run on it since today is run by two people at the same time.
Comment 2 Brion Vibber 2008-04-15 17:38:19 UTC
That's the sort of thing that INSERT IGNORE is for.
Comment 3 aaron brick 2008-04-15 18:03:12 UTC
I did also get this error on "Antananarivo, Madagascar" (funny that it'd be limited happening on capitals of poor-ass countries), but I haven't seen it since yesterday. Thanks guys.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-15 18:07:37 UTC
(In reply to comment #2)
> That's the sort of thing that INSERT IGNORE is for.

REPLACE is probably better in this case.
Comment 5 Roan Kattouw 2008-04-15 18:15:06 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > That's the sort of thing that INSERT IGNORE is for.
> REPLACE is probably better in this case.

It doesn't really matter, because they're supposed to add the exact same row. I'll use REPLACE just be sure, though.
Comment 6 Roan Kattouw 2008-04-15 18:46:12 UTC
Fixed in r33383

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