Changes between Initial Version and Version 6 of Ticket #31653
- Timestamp:
- 06/03/2020 02:03:59 PM (9 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #31653
- Property Cc Simon Charette added
-
Property
Component
changed from
Migrations
tocontrib.postgres
-
Property
Summary
changed from
PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT
toAdd PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT
-
Ticket #31653 – Description
initial v6 1 1 If you read the ALTER TABLE PostgreSQL docs ( https://www.postgresql.org/docs/12/sql-altertable.html ) for `ADD CONSTRAINT`, you'll see that it supports the `NOT VALID` option. This prevents the constraint from being checked against all existing data, although it does affect all inserted/updated rows. Adding a constraint this way does not exclusively lock the whole table to check it. To promote it to valid, the `VALIDATE CONSTRAINT` syntax can be used. This allows a non-exclusive lock on the table to validate all existing rows. This two step techinque allows constraints to be added to very active tables without locking out concurrent access and thus inflicting downtime. 2 2 3 I suggest Django always use this form when adding foreign keys and check constraints.3 I suggest `django.contrib.postgres` add custom operations for these commands, with appropriate documentation around using them in non-atomic migrations.