Today either the civicrm_contribution_after_delete or civicrm_contribution_after_update trigger went amok and locked up the db for 12k seconds. Let's drop them until we can figure out how to make them not cause a failstorm.
Unfortunately, 'show full processlist' listing refers to OLD.contact_id and not the value that fired the trigger, so we don't know which contribution was being changed.
for now, let's run:
DROP TRIGGER civicrm_contribution_after_delete; DROP TRIGGER civicrm_contribution_after_insert; DROP TRIGGER civicrm_contribution_after_update;
after_insert doesn't contain the OLD.contact_id that was in the offending query, but there's no reason to keep just one of these triggers if users won't be able to rely on wmf_donor values.