| Anomie added a comment. |
In T202032#4505934, @tstarling wrote:populateArchiveRevId.php allocated rev_id values by inserting a dummy row into the revision table and then deleting it in the same transaction. It's evident from the MariaDB documentation that this is unsafe in MariaDB 10.1. In fact even ordinary article deletion is unsafe in MariaDB 10.1: if the latest revision is deleted, and then the master DB server is restarted, the autoincrement value will be reset to MAX(rev_id)+1 and so new revision creations will reuse the ID supposedly reserved by ar_rev_id.
It's safe enough in itself. The problem is the one you identify that's shared with normal deletions too.
deduplicateArchiveRevId.php does the same thing, BTW.
In summary, I don't know what happened but it's obviously broken.
Possibly what happened for aawikibooks was that the database was already in the inconsistent state with respect to the rev_id auto-increment value when deduplicateArchiveRevId.php was run the first time, so the inserts into revision that were supposed to assign new IDs were instead duplicating other existing archive rows.
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.
I don't think so. The failed insert to slots would still have had a successful-but-rolled-back insert into revision, which would have incremented the auto-increment counter. Once enough edits failed to increment the counter past where it should be, edits would start working again.
In T202032#4506542, @daniel wrote: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.
T20493: Unify various deletion systems seems like it might go in that direction.
In T202032#4506659, @daniel wrote:I just realized, we already fixed duplicate ar_rev_id entries before... And then the problem re-appeared? That doesn't sound good.
I re-opened T193180: Clean up archive rows with duplicate revision IDs and made it a blocker for this task. @Anomie, can you look into this?
Once we somehow fix the bug where the auto-increment value is inconsistent with ar_rev_id, we should be able to just re-run deduplicateArchiveRevId.php.
We'd then want to check in case any of the reassigned rows are the ones that populateContentTables.php had populated (versus being the rows that it errored out on). Or we could just blank the slots and content tables.
Cc: gerritbot, Aklapper, daniel, aude, Addshore, Anomie, Abit, jcrespo, tstarling, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, 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
