I have just renamed https://en.wikipedia.org/wiki/Special:CentralAuth/The_Optimistic_Guy to https://en.wikipedia.org/wiki/Special:CentralAuth/RainFall. The rename appears to be successful, but after I clicked the "Rename user" button, I noticed that the page took a very long time to load. I then got a database error message: "To avoid creating high replication lag, this transaction was aborted because the write duration (75.447417974472) exceeded the 5 second limit. [...] If you are changing many items at once, try doing multiple smaller operations instead." There is no global rename log entry when seen in https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress/RainFall and https://meta.wikimedia.org/wiki/Special:Log/gblrename although RxyBotLT in #wikimedia-rename @ freenode reported the rename's log entry. Local rename log entries were correctly created, as seen at https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=renameuser&user=K6ka&page=The+Optimistic+Guy&year=&month=-1&tagfilter=
If we already have known reports about this, it is likely that there are more unknown occurrences of this elsewhere too (due to lock waits, not just long queries). Having inconsistent states seem like a pretty severe issue to me. I have written a possible explanation at T141988#2519765. @aaron Is it possible for that to happen or is there another explanation? Seems like something that need to be fixed in the short term before major bugs arise from this.
Looks like global user rename/merge have a mess of begin/commit calls that should be cleaned up (with jobs pushed to post-idle trx state or using the same trick regular RenameUser does with presend and locking).