When operating outside of transaction, add/remove versions immediately #1106
+169
−57
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brandur
force-pushed
the
brandur-single-tx
branch
2 times, most recently
from
3c53e9b to
e0e457b
Compare
|
Thanks |
bgentry
approved these changes
Dec 22, 2025
rivermigrate/river_migrate.go
Outdated
Comment on lines
424
to
425
| // When operating with an outer transaction, add/remove all versions at once | ||
| // so we can save a few database operations. |
Contributor
There was a problem hiding this comment.
This is only removing, not adding, right?
Contributor
Author
There was a problem hiding this comment.
Ah good catch. Corrected this comment.
brandur
force-pushed
the
brandur-single-tx
branch
from
e0e457b to
4a16356
Compare
We had a problem reported recently wherein a user who was executing migrations in tight contention with each other hit a problem where because a transaction is only in operation right around the immediate SQL of each migration, it's easily possible to get all the side effects of a transaction without actually adding/removing any versions. In the event of such a failure, the database is left in an irreconcilable state. Neither migrating up or down can fix the problem, with the only option being manual intervention. Here, when running without an outer transaction, run version insertion or deletion immediately so that it happens immediately inside the inner transaction, thereby preventing this problem. All `MigrateTx` test exercise was completely stripped out so I added a couple basic tests back in so that this code has some coverage.
brandur
force-pushed
the
brandur-single-tx
branch
from
4a16356 to
14e5e77
Compare
Contributor
Author
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We had a problem reported recently wherein a user who was executing
migrations in tight contention with each other hit a problem where
because a transaction is only in operation right around the immediate
SQL of each migration, it's easily possible to get all the side effects
of a transaction without actually adding/removing any versions. In the
event of such a failure, the database is left in an irreconcilable
state. Neither migrating up or down can fix the problem, with the only
option being manual intervention.
Here, when running without an outer transaction, run version insertion
or deletion immediately so that it happens immediately inside the inner
transaction, thereby preventing this problem.
All
MigrateTxtest exercise was completely stripped out so I added acouple basic tests back in so that this code has some coverage.