Last modified: 2013-03-12 22:02:32 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 14149 - Database error at undelete on dewiki
Database error at undelete on dewiki
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal critical (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-16 10:34 UTC by Raimond Spekking
Modified: 2013-03-12 22:02 UTC (History)
2 users (show)

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


Attachments

Description Raimond Spekking 2008-05-16 10:34:55 UTC
Try to undelete: 

http://de.wikipedia.org/wiki/Spezial:Wiederherstellen/Ansegis

Revisions to undelete:

#  (diff) 22:17, 14 May 2008 . . S1 
# (diff) 16:53, 13 May 2008 . . 134.109.116.3
# (diff) 16:49, 13 May 2008 . . 134.109.116.3 
# (diff) 10:21, 8 May 2008 . . Moguntiner 



Output:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    (SQL query hidden)

from within function "Revision::insertOn". MySQL returned error "1062: Duplicate entry '3559238-45783912' for key 1 (10.0.0.231)".
Comment 1 Aaron Schulz 2008-05-16 12:47:01 UTC
I'm seeing ar_rev_id = 0 for all the revisions... not sure why that would be.
Comment 2 Aaron Schulz 2008-05-16 12:49:54 UTC
I'm also seeing two deleted revs for each rev (dups)
Comment 3 Brion Vibber 2008-05-16 19:04:31 UTC
You'll have ar_rev_id = 0 for things that were deleted prior to the existence of ar_rev_id... though that shouldn't include anything from May 2008!

These do not have ar_rev_id=0, however.

They all have an actual ar_rev_id value, and there are multiples for revs 45783476 (2x) and 45783637 & 45783912 (4x).

Unique constraints aren't enforced on the archive table, and there's probably not good protection against multiple simultaneous deletions adding multiple rows before they get removed from the revision table.

It's likely there are other duplicate cases in the DB; it may be wise to add some protection, and/or to have some graceful failure for the restorations.


As a temporary workaround, try undeleting only the non-duplicate rows.
Comment 4 Aaron Schulz 2008-05-16 19:08:52 UTC
(In reply to comment #3)
> You'll have ar_rev_id = 0 for things that were deleted prior to the existence
> of ar_rev_id... though that shouldn't include anything from May 2008!

Those rows should be NULL, not zero, which is what threw me off.

Anyway, why was TS giving ar_rev_id = 0 ?

Comment 5 Aaron Schulz 2008-09-16 18:45:33 UTC
Fixed in r40923

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


Navigation
Links