From: Álvaro Herrera Date: Thu, 21 Nov 2024 15:54:36 +0000 (+0100) Subject: Fix outdated bit in README.tuplock X-Git-Tag: REL_18_BETA1~1451 X-Git-Url: http://git.postgresql.org/gitweb/?a=commitdiff_plain;h=7300ff1bd8fa64c0feab1d490b709d553e9a438e;p=postgresql.git 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 Discussion: https://postgr.es/m/CAMpnoC6yEQ=c0Rdq-J7uRedrP7Zo9UMp6VZyP23QMT68n06cvA@mail.gmail.com --- 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 ----------