Skip to content

Commit 8764de4

Browse files
authored
Document Adding indexes (#3594)
1 parent e88e25f commit 8764de4

File tree

2 files changed

+30
-1
lines changed

2 files changed

+30
-1
lines changed

contributing/MIGRATIONS.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,3 +47,29 @@ These steps apply to **renaming a column** or **changing the type of a column**
4747
### Altering multiple tables
4848

4949
Altering a table requires Postgres to [take an ACCESS EXCLUSIVE lock](https://www.postgresql.org/docs/current/sql-altertable.html). (This applies not only to statements that rewrite the tables but also to statements that modify tables metadata.) Altering multiple tables can cause deadlocks due to conflict with read operations since the `dstack` server does not define an order for read operations. Altering multiple tables should be done in separate transactions/migrations.
50+
51+
### Adding indexes
52+
53+
Use `CREATE INDEX CONCURRENTLY` to avoid tacking exclusive lock on the table for a long time.
54+
For migrations that create multiple indexes, failures can leave the schema in a partial state
55+
(some indexes already created, some missing). On Postgres, concurrent index creation can also fail
56+
midway and leave an invalid index object with the same name. Retrying the migration then fails
57+
with "already exists".
58+
59+
For retry-safe migrations, pre-drop indexes with `if_exists=True` before creating them again:
60+
61+
```python
62+
with op.get_context().autocommit_block():
63+
op.drop_index(
64+
"ix_table_col",
65+
table_name="table",
66+
if_exists=True,
67+
postgresql_concurrently=True,
68+
)
69+
op.create_index(
70+
"ix_table_col",
71+
"table",
72+
["col"],
73+
postgresql_concurrently=True,
74+
)
75+
```

contributing/RELEASE.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,10 @@ This is a `dstack` release guide and checklist for core maintainers.
88
1. Compare changes to the previous release, e.g. [`https://github.com/dstackai/dstack/compare/0.19.39...master`](https://github.com/dstackai/dstack/compare/0.19.39...master).
99
2. Test that `master` CLI works with the previous server release. PRs that add new model fields can potentially break client backward compatibility.
1010
3. Test that `master` server works with the previous CLI release.
11-
4. Pay special attention to releases with DB migrations. Migrations should work with rolling deployments and avoid locking multiple tables. See [MIGRATIONS.md](MIGRATIONS.md).
11+
4. Pay special attention to releases with DB migrations. See [MIGRATIONS.md](MIGRATIONS.md).
12+
* Ensure migrations work with rolling deployments and do not lock multiple tables.
13+
* Test applying migrations while old replicas do active processing.
14+
* Test migrations can be retried if they fail. For example, concurrent index may fail and stay in invalid state.
1215
2. Create a tag, e.g. `git tag 0.19.40`.
1316
3. Push the tag to trigger the Release `workflow`, i.e. `git push --tags`.
1417
4. Generate GitHub release notes from the tag. Highlight major features, deprecations, breaking changes.

0 commit comments

Comments
 (0)