postgres.git / summary / log / commit / refs

commit    7300ff1bd8fa64c0feab1d490b709d553e9a438e
Author:   Álvaro Herrera <alvherre@alvh.no-ip.org>
Date:     Thu Nov 21 15:54:36 2024 +0000
First released in: 18.0, 13.19, 14.16, 15.11, 16.7, 17.3

    Fix outdated bit in README.tuplock
    
    Apparently this information has been outdated since first committed,
    because we adopted a different implementation during development per
    reviews and this detail was not updated in the README.
    
    This has been wrong since commit 0ac5ad5134f2 introduced the file in
    2013.  Backpatch to all live branches.
    
    Reported-by: Will Mortensen <will@extrahop.com>
    Discussion: https://postgr.es/m/CAMpnoC6yEQ=c0Rdq-J7uRedrP7Zo9UMp6VZyP23QMT68n06cvA@mail.gmail.com


 src/backend/access/heap/README.tuplock | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/backend/access/heap/README.tuplock b/src/backend/access/heap/README.tuplock
index 31c52ad28f9..843c2e58f92 100644
--- a/src/backend/access/heap/README.tuplock
+++ b/src/backend/access/heap/README.tuplock
@@ -70,13 +70,8 @@ KEY SHARE        conflict
 
 When there is a single locker in a tuple, we can just store the locking info
 in the tuple itself.  We do this by storing the locker's Xid in XMAX, and
-setting infomask bits specifying the locking strength.  There is one exception
-here: since infomask space is limited, we do not provide a separate bit
-for SELECT FOR SHARE, so we have to use the extended info in a MultiXact in
-that case.  (The other cases, SELECT FOR UPDATE and SELECT FOR KEY SHARE, are
-presumably more commonly used due to being the standards-mandated locking
-mechanism, or heavily used by the RI code, so we want to provide fast paths
-for those.)
+setting infomask bits specifying the locking strength.  See "Infomask Bits"
+below for details on the bit patterns we use.
 
 MultiXacts
 ----------


[parent: 79b575d3bc09]