4 ms·
One caveat regarding "Always put each migration into a database transaction": I've found that for very large database tables on a live system, it becomes imprac
by keithlfrost 9y ago
One caveat regarding "Always put each migration into a database transaction": I've found that for very large database tables on a live system, it becomes impractical to e.g. create a new index inside a transaction, because the entire table would need to be locked for the duration of the operation.
- X86BSD 9y agoIs this not what PostgreSQL's MVCC was created to help mitigate? https://www.postgresql.org/docs/current/static/mvcc-intro.html https://www.postgresql.org/docs/current/static/mvcc-intro.ht...
- notyourday 9y agoThat's because this entire approach is broken: if one cannot afford to bring database down to do alter table migration, one should always go a lazy migration either via application stack using write-to-new only, read from new on miss, read from old, followed by a backfill or using triggers.