Add a hack to make migration deadlocks less likely in some common cases #6379
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a partial mitigation of #6304.
There are a lot of opportunities for deadlocks between DDL
(which can take a lot of full locks on things) and
long-running queries. One place this comes up is with views,
since recreating a view requires a lock. When adding things to
tables, our DDL must modify the table, then modify the view.
This poses a deadlock risk with queries, which nearly always
will access the view before accessing the table (since the table
is how they get to the view).
Put a hacky and hopefully temporary bandage around this particular
deadlock case by injecting a no-op ALTER VIEW before the first
ALTER of some table. This ensures that DDL locks the inhview
before the real table, making the lock order match the typical
query lock order.