Page MenuHomePhabricator

Disable new wmf_donor triggers while we make them not lock the db
Closed, ResolvedPublic

Description

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.

Event Timeline

Ejegg created this task.Jul 26 2019, 12:36 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 26 2019, 12:36 AM
Ejegg assigned this task to Jgreen.Jul 26 2019, 12:43 AM
Ejegg triaged this task as Unbreak Now! priority.
Ejegg updated the task description. (Show Details)
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptJul 26 2019, 12:43 AM

Triggers are removed as of 08:43:23 PM EDT.

I had to kill the long-running query first.

The most likely problem point would be the date of latest largest field - perhaps a contact with many donations of the same amount caused the issue ? I didn't hit it in my testing but that felt like the least robust piece in the puzzle

Jgreen closed this task as Resolved.Jul 31 2019, 8:14 PM
Jgreen moved this task from Backlog to Done on the fundraising-tech-ops board.