Repository navigation
fix(engine): migration deadlocks - #5357
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
 [Medium impact] The change reaches OLAP aggregate setup and the counts gathered from run, task-event, and event writes. Keep the three status triggers atomic before merging so live upgrades cannot leave status counts wrong. SummaryThis PR changes the aggregate migration to release locks between trigger creations and makes object creation safe to repeat.
Reviews (1) · Last reviewed commit: "fix: migration deadlocks" · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| CREATE OR REPLACE TRIGGER v1_agg_task_statuses_insert_trigger | ||
| AFTER INSERT ON v1_runs_olap | ||
| REFERENCING NEW TABLE AS new_rows | ||
| FOR EACH STATEMENT | ||
| EXECUTE FUNCTION v1_agg_task_statuses_insert_fn(); | ||
|
|
||
| CREATE TRIGGER v1_agg_task_statuses_update_trigger | ||
| CREATE OR REPLACE TRIGGER v1_agg_task_statuses_update_trigger |
There was a problem hiding this comment.
If an existing engine keeps writing during migration, installing the three v1_runs_olap triggers in separate transactions can leave counts wrong. After the insert trigger commits but before the update trigger commits, a run can be inserted as QUEUED and then finish. The insert adds a queued count, but the update produces no matching change, so the run stays counted as queued. A failure while creating the update trigger extends this window.
The compactor only adds recorded changes; it cannot repair the missed update. Keep these three triggers in one transaction while installing triggers for other tables separately.
Description
Running this without a tx because the trigger creations can deadlock
Type of change
Checklist
Changes have been:
🤖 AI Disclosure
No AI