https://bugzilla.wikimedia.org/show_bug.cgi?id=35047
--- Comment #18 from Tim Starling <[email protected]> 2012-03-23 05:39:22 UTC --- There are a few different issues here. (In reply to comment #0) > On Commons, nowadays we sometimes notice that after a file deletion via API, > the file-revision-table remains visible and links to the files are not > rendered > as redlinks. Purging helps but if you delete, you do not expect having to go > to > the page and purge it. The slave DB is used to check page_touched in response to an IMS request, so if the file description page looks identical to how it looked before delete, then slave lag coupled with session corruption is a possibility. If the description page had no description text, but the "file history" section was still present, then that would point to an incomplete delete operation. In my test install for a file deletion, I count four separate transactions with write queries in them. The deletion of the image row happens after the deletion of the page row, so it's possible for the page to be deleted before the image, and it's possible for this situation to be user-visible. If everything seemed fine after a few minutes then it was probably just slow rather than broken. (In reply to comment #1) > All 3 files I deleted in the last 5 minutes however are different, something > weird happened (or rather, didn't happen). The category member links were kept > and after refreshing they're still showing up in the category (although the > thumbnail is broken, and opening the link shows a "This page was recently > deleted" message). When an image is deleted, the page_touched for the categories it is in are not updated. It's probably been that way since categories were invented, I confirmed it back to 1.17. The code to do this purge is just not there. This is not related to the other reports. (In reply to comment #5) > After two minutes, the first five files are still highlighted in gray with > "working". The last six are all red. If recent experience is true here, they > will remain "working" indefinitely -- I once left them overnight without > change. Maybe an unexpected result from api.php caused the gadget to throw an exception. In any case, failure to show an informative error message is a gadget problem, not a server problem. > > If I then reload the DR page, several things can happen. > 1) In this case, they all show up red. This is true less than half the time > 2) In most cases some or all will will remain blue. There's a few possible causes of that. > 2a) Then if I go to the file page, in some cases the file will be intact. > 2b) In other cases, the file will appear intact, but the pulldown will start > with "Undelete", showing that the file is actually gone. In that case, using > "Purge" on the pulldown will turn it red on the DR page. The deleted status used by the skin comes from the slave DB, so this could be either slave lag or an incomplete delete operation. (In reply to comment #14) > from within function "LocalFile::delete". Database returned error "1205: Lock > wait timeout exceeded; try restarting transaction (10.0.6.41)". This is the site_stats update, an exception thrown here will cause the memcached file cache update and LocalFile::purgeThumbList() to be skipped. Those two things are done in the same transaction, and LocalFile::purgeThumbList() is quite slow. But I'm not sure if it will explain all of the problems on this bug report. I'll look at dberror.log, it will tell us whether this lock wait timeout is common. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
