Skip to content

Safely create alembic_version table and add the correct stamps#192

Closed
wgresshoff wants to merge 22 commits intoinveniosoftware:masterfrom
ulbmuenster:create-alembic-version-safely
Closed

Safely create alembic_version table and add the correct stamps#192
wgresshoff wants to merge 22 commits intoinveniosoftware:masterfrom
ulbmuenster:create-alembic-version-safely

Conversation

@wgresshoff
Copy link

❤️ Thank you for your contribution!

Description

After a fresh setup of an InvenioRDM instance the alembic_version table was missing which leads to problems when migrating to a newer version. This PR adds a transaction context around the table creation and makes sure the correct connection is used, thus avoiding working in a connection ghost that never got committed.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

Frontend

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

  1. You license your contribution under the same terms as the current repository’s license.
  2. You agree that you have the right to license your contribution under the current repository’s license.

utnapischtim and others added 19 commits February 26, 2026 12:55
* with that it is possible to solve the datetime.utcnow DeprecationWarnings
* the new version 1.6.0 produces errors in alembic tests in other
  packages. i stats that indices which should be there are not there

* an example package is invenio-pages
* Right now, we don't have any restriction/requirement on the database's
time zone. This can lead to unexpected behaviour when reading/writing
timestamps with time zones, since they get shifted to the database's
zone which might not be UTC.

* The easiest way to ensure the DB is using UTC is by specifying it on
connection via SQLAlchemy. This overrides any default value specified in
e.g. postgresql.conf.

* Instances can still easily override this if they should need to, but
this is not recommended.
DDL migrations acquire ACCESS EXCLUSIVE locks which can cause cascading
blocking on busy tables. This sets lock_timeout (default 1s) on
PostgreSQL migration connections so they fail fast instead of blocking
reads indefinitely. On lock_not_available (pgcode 55P03), retries with
exponential backoff and jitter. Already-applied steps are skipped on
retry thanks to transaction_per_migration version stamping.

Configurable via DB_MIGRATION_LOCK_TIMEOUT (default "1s", set "0" to
disable) and DB_MIGRATION_LOCK_TIMEOUT_RETRIES (default 5).

See https://postgres.ai/blog/20210923-zero-downtime-postgres-schema-migrations-lock-timeout-and-retries
@wgresshoff
Copy link
Author

Closed in favor of #202

@wgresshoff wgresshoff closed this Mar 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants