From aca1599d694d672d65d4f9d2f8378bb93de14c7b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= Date: Thu, 21 Nov 2024 16:54:36 +0100 Subject: [PATCH] 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 --- 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 818cd7f9806..750684d3398 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 ----------