Back-fill action_trigger.event complete_time values

Bug #1690418 reported by Bill Erickson on 2017-05-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Continuation of bug #1672824 which addresses the lack of action_trigger.event.complete_time values for grouped events, for consideration in 3.0.


Is it worth adding an update script that tries to clean this up? If so, given the potentially large number of rows to update, should the update be spun off into a separate wishlist for 3.0?

Something along the lines of this?

update action_trigger.event set complete_time = update_time where state = 'complete' and complete_time is null;

We likely want this update to run outside of the main upgrade transaction.

Bill Erickson (berick) on 2017-05-12
summary: - Back-fill action_trigger complete_time values
+ Back-fill action_trigger.event complete_time values
Bill Erickson (berick) on 2017-05-12
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
milestone: none → 3.0-alpha
Dan Wells (dbw2) wrote :

I gave this script a go on our production server, and it updated ~200,000 rows in under two seconds. I know bigger installs will take more time, but even a factor of 10 or 20 feels within the range of a "normal" upgrade script.

For simplicity's sake, I wouldn't mind seeing this rolled into the parent bug upgrade script for all versions.

Bill Erickson (berick) wrote :

Assuming comparable delete times, It'll be >20 minutes here (136M rows). That may be an outlier (and I can always tweak the upgrade locally), but keeping the deletes out of the main upgrade transaction still seems like the better approach. I think it can be in the same script, just at the end, post-transaction.

Bill Erickson (berick) wrote :

And thanks for testing that Dan, because I had not collected any data yet to justify the concern. I'm trying a proper delete (w/ rollback) now on a test server to see what happens.

Bill Erickson (berick) wrote :

Noting that I meant to say 'comparable update times' not 'delete' times a few comments up.

Dan Wells (dbw2) wrote :

Well, I guess if 680x larger is on the table, then maybe this is the proper level of precaution :)

Changed in evergreen:
milestone: 3.0-beta → 3.0-beta2
Changed in evergreen:
milestone: 3.0-beta2 → 3.0-rc
Galen Charlton (gmc) on 2017-09-27
Changed in evergreen:
milestone: 3.0-rc →
tags: added: actiontrigger
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers