From: Alpha Shuro <alphashuro@gmail.com>
To: pgsql-docs@lists.postgresql.org
Cc: Alpha Shuro <alphashuro@gmail.com>
Subject: [DOCS] document ShareLock behaviour when using a deferred unique
 index
Date: Wed, 15 Oct 2025 21:07:27 +0200
Message-ID: <20251015190727.61226-1-alphashuro@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/20251015190727.61226-1-alphashuro%40gmail.com>
Precedence: bulk

The logs that were printed by Postgres
when enforcing deferred unique indexes were misleading.

This change should make it easier to understand or investigate
when users see the `waits for ShareLock` log entry
---
 doc/src/sgml/mvcc.sgml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 049ee75a4ba..4e36c59776a 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1003,32 +1003,37 @@ ERROR:  could not serialize access due to read/write dependencies among transact
       <varlistentry>
        <term>
         <literal>SHARE</literal> (<literal>ShareLock</literal>)
        </term>
        <listitem>
         <para>
          Conflicts with the <literal>ROW EXCLUSIVE</literal>,
          <literal>SHARE UPDATE EXCLUSIVE</literal>, <literal>SHARE ROW
          EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>, and
          <literal>ACCESS EXCLUSIVE</literal> lock modes.
          This mode protects a table against concurrent data changes.
         </para>

         <para>
          Acquired by <command>CREATE INDEX</command>
          (without <option>CONCURRENTLY</option>).
+
+         It is also acquired when enforcing a DEFERRED UNIQUE INDEX:
+         If a transaction detects another transaction that might cause
+         a potential conflict, it waits for the other transaction to complete,
+         by acquiring a ShareLock on the other transaction's transaction id.
         </para>
        </listitem>
       </varlistentry>
--
2.51.0