| daniel added a comment. |
The MCR write-both mode, with its unique index on slot_revision_id, should at least prevent conflicting rows from being inserted, although this potentially comes at the cost of throwing an exception on every edit until someone manually advances the autoincrement value for rev_id is advanced beyond MAX(ar_rev_id).
There already is a unique index on rev_id, and during normal operation, new slot rows are only created when new revision rows are created. The only exception is the populateContentTables.php script. As Tim noted, that script did throw an exception when encountering the duplicate ar_rev_id values.
That is to say, if the most recent revision is deleted, and then a master switch is done, all edits would fail until manual action is taken.
If the master switch causes the auto-increment counter for rev_id to be reset, this could indeed happen. It's very unlikely, but if it did happen, it would be very annoying.
Is there a good way to see whether a DBError is caused by a primary key conflict? If we had a way to detect this, we could fall back to determining the new rev_id from SELECT MAX(slot_revision_id)+1. Maybe we could even just always do this, instead of relying on rev_id's auto-increment... but I'm not 100% sure that would be safer and performant. Would it?
In the long term, we will have to stop using ar_rev_id, since evidently we made incorrect assumptions about how DBMSs work. The whole concept of ar_rev_id appears to be invalid.
I don't see any alternative to ar_rev_id, unless we stop using the archive table altogether.
A quick hack would be to permanently insert a row into the revision table of the affected wikis, with a rev_id specified so as to make room for the extra ar_rev_id values. This wouldn't fix the master switch issue.
...and of course, we'd have to actually assign the extra ar_rev_id values.
When inserting a row into revision, we could do SELECT MAX(ar_rev_id) FROM archive. If the rev_id returned when inserting is less than MAX(ar_rev_id), then we could update the rev_id in the newly-inserted row to some larger value.
I'd prefer to use MAX(slot_revision_id), since that's the actual primary index. But I suppose that amounts to the same, does it not?
I'll make a patch for this. Please confirm that the additional query on master isn't a performance problem.
Cc: Aklapper, daniel, aude, Addshore, Anomie, Abit, jcrespo, tstarling, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, JJMC89, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
