Also flag concurrent index creation

Creating indices concurrently (provided that index creation *completes*)
is generally a much safer way to build an index (since it allows reads
*and* writes to the table during index creation).

However, due to the inherent tradeoffs of concurrent index creation, the
operation will almost always take *longer* than a traditional (blocking)
index creation. It's actually much *more* important to lint against
concurrent index creation when an exclusive lock is open & held.

Test is from a comment by @David-Wobrock (I corrected syntax, though):
https://github.com/3YOURMIND/django-migration-linter/pull/251#discussion_r1249298197
This commit is contained in:
David Cain authored and David Wobrock committed 2023-07-09 14:42:35 +02:00
1 parent 15dbe22f24
commit 86b660fbf6
2 files changed
+22 -4

No files matched your search

+18
View File
@@ -331,6 +331,17 @@ class PostgresqlAnalyserTestCase(SqlAnalyserTestCase):
]
self.assertWarningSql(sql, code="CREATE_INDEX_EXCLUSIVE")
def test_create_concurrently_index_exclusive(self):
sql = [
"BEGIN;",
'ALTER TABLE "users" ADD COLUMN "email" varchar(254) NULL;',
# Counter-intuitively, concurrent index creation can take *longer*.
# It's especially important that we flag an exclusive lock being held.
'CREATE INDEX CONCURRENTLY "user_email" ON "users" ("email");',
"COMMIT;",
]
self.assertWarningSql(sql, code="CREATE_INDEX_EXCLUSIVE")
def test_create_index_exclusive_no_lock(self):
sql = [
'ALTER TABLE "users" ADD COLUMN "email" varchar(254) NULL;',
@@ -339,6 +350,13 @@ class PostgresqlAnalyserTestCase(SqlAnalyserTestCase):
# Will warn about `CREATE_INDEX`, but *not* `CREATE_INDEX_EXCLUSIVE`
self.assertValidSql(sql, allow_warnings=True)
def test_create_index_exclusive_concurrently_no_lock(self):
sql = [
'ALTER TABLE "users" ADD COLUMN "email" varchar(254) NULL;',
'CREATE INDEX CONCURRENTLY "user_email" ON "users" ("email");',
]
self.assertValidSql(sql)
class SqlUtilsTestCase(unittest.TestCase):
def test_unknown_analyser_string(self):