Though it might be unwise anyhow to run migrations on a database in parallel with a running migration, this seems to be worth reporting:
The migration introduced with b04ef3f cannot be applied (in neither direction) when at the same time a ringo application is running with the same database.
The reason are blocking statements from the setup-phase of the application, which can be shown by the following steps:
set level = INFO for the logger_sqlalchemy in your ini-file and start your application with pserve. In another Shell run the mentioned migration (with either upgrade or downgrade, depending on the current state of your database). You can observe now, that the migration process hangs at
INFO [alembic.runtime.migration] Running upgrade 550b15a3086d -> 4618c1f51917, Make UUIDs NOT NULL.
Open a psql Shell connecting to your PostgreSQL-Server and run the statement here https://wiki.postgresql.org/wiki/Lock_Monitoring#.D0.A1ombination_of_blocked_and_blocking_activity.
If you add timestamps like blocking_activity.query_start and blocked_activity.query_start you can find out that the blocking queries have been started during the startup of pserve.
Obviously, there are transactions started during application startup that acquire locks and are not ended until the application is stopped. This might have other side effects than that described above, too.
Though it might be unwise anyhow to run migrations on a database in parallel with a running migration, this seems to be worth reporting:
The migration introduced with b04ef3f cannot be applied (in neither direction) when at the same time a ringo application is running with the same database.
The reason are blocking statements from the setup-phase of the application, which can be shown by the following steps:
set
level = INFOfor thelogger_sqlalchemyin your ini-file and start your application withpserve. In another Shell run the mentioned migration (with eitherupgradeordowngrade, depending on the current state of your database). You can observe now, that the migration process hangs atINFO [alembic.runtime.migration] Running upgrade 550b15a3086d -> 4618c1f51917, Make UUIDs NOT NULL.Open a
psqlShell connecting to your PostgreSQL-Server and run the statement here https://wiki.postgresql.org/wiki/Lock_Monitoring#.D0.A1ombination_of_blocked_and_blocking_activity.If you add timestamps like
blocking_activity.query_startandblocked_activity.query_startyou can find out that the blocking queries have been started during the startup ofpserve.Obviously, there are transactions started during application startup that acquire locks and are not ended until the application is stopped. This might have other side effects than that described above, too.