Hi,
I believe that the description of which transactions will block a CREATE
INDEX CONCURRENTLY command from proceeding isn't right.
Please find the attached patch.
Best regards,
Frédéric
From cf3ecfda5155584e7c1d81c5daaf04e78d4fddef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?= <frederic.yh...@dalibo.com>
Date: Wed, 9 Jul 2025 15:44:49 +0200
Subject: [PATCH] Fix documentation about CREATE INDEX CONCURRENTLY.
Fix the description of which transactions will block a
CREATE INDEX CONCURRENTLY command from proceeding.
This is actually a minor fixup for a65313f28bfc.
In DefineIndex(), we call WaitForLockers(heaplocktag, ShareLock, true),
and the heaplocktag is set with the relid of the heap, which means that
we wait for all the transactions that acquired a lock >= ROW EXCLUSIVE
on the heap.
---
doc/src/sgml/ref/create_index.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index b9c679c41e8..d152e603220 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -622,7 +622,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
When this option is used,
<productname>PostgreSQL</productname> must perform two scans of the table, and in
addition it must wait for all existing transactions that could potentially
- modify or use the index to terminate. Thus
+ modify the indexed table to terminate. Thus
this method requires more total work than a standard index build and takes
significantly longer to complete. However, since it allows normal
operations to continue while the index is built, this method is useful for
--
2.47.2
