Currently, the plugin uses a separate connection to manage schema history table and migrations are applied in another thread.
This was causing catalog version mismatch issues when one thread altered catalog version while another was querying a pg_catalog.pg_class table inside a transaction.
The fix is to use single connection for both schema history table management and applying migrations
Also, made the tableEntries map a static variable in YugabyteDBExecutionTemplate
This map keeps track of which entries are added to the lock table across different migrations from within the same app. Earlier, being an instance variable it was getting reinitialised for each migration and not serving its purpose.
What
pg_catalog.pg_class
table inside a transaction.tableEntries
map a static variable inYugabyteDBExecutionTemplate
Testing
Ran modified tests from flyway-tests repository. PR available https://github.com/yugabyte/flyway-tests/pull/3.