Page MenuHomePhabricator

Do not refresh file metadata for huge files on purge, and especially do not do it well holding database locks
Closed, ResolvedPublic

Details

Reference
bz43331

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:01 AM
bzimport set Reference to bz43331.
bzimport added a subscriber: Unknown Object (MLST).

WikiFilePage calls $this->mFile->upgradeRow() in doPurge(), which is wildly inappropriate in this case. Maybe something like the 'forRefresh' flag for thumbnail purging can also be applied here. It could also use the job queue instead.

component -> file management. Really not a db problem (other then the db locks are held during purging, which probably shouldn't be)

(In reply to comment #1)

WikiFilePage calls $this->mFile->upgradeRow() in doPurge(), which is wildly
inappropriate in this case. Maybe something like the 'forRefresh' flag for
thumbnail purging can also be applied here. It could also use the job queue
instead.

To be more specific this would only be for large files (and could work similar to the TimedMediaHandler extension).

Created attachment 13660
@2013-11-01 19:19:51 UTC

Attached:

error.PNG (291×1 px, 24 KB)

(In reply to comment #4)

Hello,

I got the same message while deleting files:
https://commons.wikimedia.org/w/index.php?title=File:
Moraglia_serve_alla_mensa_dei_poveri_Ca_Letizia_24-03-2012.jpg&action=delete
A database query error has occurred. This may indicate a bug in the software.

Function: WikiPage::pageData
Error: 1205 Lock wait timeout exceeded; try restarting transaction
(10.64.32.29)

Also for
https://commons.wikimedia.org/wiki/File:Krystal_Jung.png
https://commons.wikimedia.org/wiki/File:Demy_The_Sun.jpg
https://commons.wikimedia.org/wiki/File:Yuri_boyka_brother..jpg
https://commons.wikimedia.org/wiki/File:Sampaio_1972_campe%C3%A3o.png
https://commons.wikimedia.org/wiki/File:Sampaio_1938.png

It is a serious problem if we can't delete files.

House keeping reference - I advised Yannf to file bug 56487 for this, as it seems unlikely the deadlock surounding file metadata extraction is the same cause as a deadlock during deletion.

Unlicking this cookie. This would be a good bug for the current multimedia team to examine.

Umherirrender subscribed.

WikiFilePage calls $this->mFile->upgradeRow() in doPurge(), which is wildly inappropriate in this case. Maybe something like the 'forRefresh' flag for thumbnail purging can also be applied here. It could also use the job queue instead.

The call was removed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/286925 to improve T132921, the purge of the file in task description is working.