A suggested fix for #1950.
If no transactions are disabled (neither in the general migration configuration nor in any individual migration file) then the whole migration to the latest version (including the acquisition of the lock and its release) is done in the same transaction which either completely succeeds or completely fails.
Among other benefits, this makes migrating to latest in parallel possible (e.g. in the bootstrap of multiple servers) since another process will automatically wait while another is migrating instead of failing with a lock error and crashing.
I had to fix some existing tests to adjust to this new behavior and I've also added a couple of new ones which test parallel migrations.
Please review :)
…s are transactional.
…ferently in other databases).
elhigu left a comment
Some indentations were a bit strange leading to:
drifting of indentation level even that promise chain is not nesting... Code looks really clean and I couldn't find anything to complain
Looks like this is already fine for merging. Thanks a lot for the effort you've been putting to this!
I added couple of questions to comments in parts that I didn't understand why it was done like that...