-
Notifications
You must be signed in to change notification settings - Fork 963
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
Timeout migrations that take too long to run #11704
Conversation
I just want to explicitly call this out: With this PR, Migrations will FAIL if they sit waiting on a lock for more than 4s. With this PR, Migrations will FAIL if any individual statement takes more than 5s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love this rather simple and direct solution! As a default value these are stellar, and the ease of overriding is great.
Can we add docs for how to manage these on a per migration basis to the development/database-migrations doc and to the migration template?
Once that's complete, this is 👍🏼
Oh oh oh! Missed your comment while writing mine. Add those links to the migrations docs too 😂 |
Co-authored-by: Dustin Ingram <[email protected]>
This will prevent migrations that take too long from locking up the site.
We might also want to set timeouts on the site itself, but I'll leave that to another PR.
This should be override-able on a per migration basis by issuing the same
SET
as part of the migration, but then it's obvious that is happening.The
lock_timeout
is how long a migration can sit there idle waiting on a lock (this will prevent other long running txns from blocking this txn, then having this txn block other txns).The
statement_timeout
will prevent any individual statement from taking more than 5s.This failing ends up looking like this: