As of today, if you try to call collection.Version(db) when a migration is running, it will wait for the LOCK TABLE gopg_migrations lock to be released before returning.
If you have long-running migrations (e.g. CREATE INDEX CONCURRENTLY ... that is running in background) and other pieces of code that rely on getting the current database version, this becomes a problem.
I stumbled upon this issue when trying to start services that checked the current database version at startup while a long-running migration was executed.
To allow this use case, we can update the lock command to LOCK TABLE ? IN EXCLUSIVE MODE which allows concurrent SELECT commands to be run on the migrations table, while still forbidding other operations.
From the documentation:
The EXCLUSIVE mode allows only concurrent ACCESS SHARE locks, i.e., only reads from the table can proceed in parallel with a transaction holding this lock mode.
As of today, if you try to call
collection.Version(db)
when a migration is running, it will wait for theLOCK TABLE gopg_migrations
lock to be released before returning.If you have long-running migrations (e.g.
CREATE INDEX CONCURRENTLY ...
that is running in background) and other pieces of code that rely on getting the current database version, this becomes a problem.I stumbled upon this issue when trying to start services that checked the current database version at startup while a long-running migration was executed.
To allow this use case, we can update the lock command to
LOCK TABLE ? IN EXCLUSIVE MODE
which allows concurrent SELECT commands to be run on the migrations table, while still forbidding other operations.From the documentation:
See:
I've targeted the
v7
branch for this patch, sincev8
is not released yet. I can update this pull request if this is not the best target.Thanks,