I'm seeing ar_rev_id = 0 for all the revisions... not sure why that would be.

I'm also seeing two deleted revs for each rev (dups)

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.

(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 ?

Fixed in r40923

In T16149#187771, @brion wrote:

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.

Revision ID collisions can also be caused by T135851: Preserve InnoDB table auto_increment on restart.