Back-fill action_trigger.event complete_time values

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

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.

Summarizing:

==
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 → 3.next
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