Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: try to prevent deadlocks when running upgrade #29625

Conversation

sadpandajoe
Copy link
Member

@sadpandajoe sadpandajoe commented Jul 18, 2024

SUMMARY

When running the migration upgrade path for #28704, we noticed that there could be times where we see a deadlock. This PR breaks down each drop into it's own migration file.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@sadpandajoe sadpandajoe requested a review from a team as a code owner July 18, 2024 00:11
@github-actions github-actions bot added the risk:db-migration PRs that require a DB migration label Jul 18, 2024
constraint = fk["name"]
if constraint:
op.execute(
f"ALTER TABLE {table} RENAME CONSTRAINT {constraint} TO {constraint}_old"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may have helped in my earlier PR when we were changing the constraint, but after looking into this, I don't think it will help when dropping the constraint. Maybe one idea would be to drop each table in a separate transaction and commit after each drop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

careful a commit may leave a migration partially applied

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I revised this to just drop the constraint first and then afterwards to drop the table. Hopefully this will reduce any deadlocks there may be.

Copy link

codecov bot commented Jul 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.70%. Comparing base (76d897e) to head (403551b).
Report is 593 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #29625       +/-   ##
===========================================
+ Coverage   60.48%   83.70%   +23.21%     
===========================================
  Files        1931      527     -1404     
  Lines       76236    38069    -38167     
  Branches     8568        0     -8568     
===========================================
- Hits        46114    31866    -14248     
+ Misses      28017     6203    -21814     
+ Partials     2105        0     -2105     
Flag Coverage Δ
hive 49.01% <ø> (-0.15%) ⬇️
javascript ?
mysql 76.78% <ø> (?)
postgres 76.86% <ø> (?)
presto 53.56% <ø> (-0.25%) ⬇️
python 83.70% <ø> (+20.21%) ⬆️
sqlite 76.34% <ø> (?)
unit 60.36% <ø> (+2.73%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

"sl_datasets"
]

def drop_constraints(table, insp):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function seems useful and could be moved into superset/migrations/shared/utils.py so it can be reused in future migrations. I'd make both insp and conn arguments so the caller can reuse theirs and control transations.

@pull-request-size pull-request-size bot added size/L and removed size/M labels Jul 18, 2024
@mistercrunch
Copy link
Member

Just a note, but in light of #29546, thinking in the future this type of migration would have been held up until the next major. In the meantime, it's probably ok to mitigate existing migrations to minimize deadlock/downtime.

@sadpandajoe sadpandajoe added the v4.1 Label added by the release manager to track PRs to be included in the 4.1 branch label Aug 15, 2024
Copy link
Member

@eschutho eschutho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran the upgrade and downgrade a few times and no issues.

@sadpandajoe sadpandajoe merged commit 2cc07e6 into apache:master Aug 16, 2024
39 checks passed
@sadpandajoe sadpandajoe deleted the joe/prevent-postgres-deadlock-for-remove-sl_tables branch August 16, 2024 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
risk:db-migration PRs that require a DB migration size/XL v4.1 Label added by the release manager to track PRs to be included in the 4.1 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants