postgres.git / summary / log / commit / refs

commit    a59b03995a4d34e09c3eeb07bc18231770b5cc09
Author:   David Rowley <drowley@postgresql.org>
Date:     Tue Dec 09 01:42:11 2025 +0000
First released in: 15.16, 16.12, 17.8, 18.2

    Doc: fix typo in hash index documentation
    
    Plus a similar fix to the README.
    
    Backpatch as far back as the sgml issue exists.  The README issue does
    exist in v14, but that seems unlikely to harm anyone.
    
    Author: David Geier <geidav.pg@gmail.com>
    Discussion: https://postgr.es/m/ed3db7ea-55b4-4809-86af-81ad3bb2c7d3@gmail.com
    Backpatch-through: 15


 doc/src/sgml/hash.sgml         | 9 ++++-----
 src/backend/access/hash/README | 9 ++++-----
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml
index 9e69ef91fe8..34f3b2cb0c1 100644
--- a/doc/src/sgml/hash.sgml
+++ b/doc/src/sgml/hash.sgml
@@ -125,11 +125,10 @@
   Both scanning the index and inserting tuples require locating the bucket
   where a given tuple ought to be located. To do this, we need the bucket
   count, highmask, and lowmask from the metapage; however, it's undesirable
-  for performance reasons to have to have to lock and pin the metapage for
-  every such operation. Instead, we retain a cached copy of the metapage
-  in each backend's relcache entry. This will produce the correct bucket
-  mapping as long as the target bucket hasn't been split since the last
-  cache refresh.
+  for performance reasons to have to lock and pin the metapage for every such
+  operation. Instead, we retain a cached copy of the metapage in each
+  backend's relcache entry. This will produce the correct bucket mapping as
+  long as the target bucket hasn't been split since the last cache refresh.
  </para>
 
  <para>
diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README
index 13dc59c124a..fc9031117c9 100644
--- a/src/backend/access/hash/README
+++ b/src/backend/access/hash/README
@@ -171,11 +171,10 @@ Metapage Caching
 Both scanning the index and inserting tuples require locating the bucket
 where a given tuple ought to be located.  To do this, we need the bucket
 count, highmask, and lowmask from the metapage; however, it's undesirable
-for performance reasons to have to have to lock and pin the metapage for
-every such operation.  Instead, we retain a cached copy of the metapage
-in each backend's relcache entry.  This will produce the correct
-bucket mapping as long as the target bucket hasn't been split since the
-last cache refresh.
+for performance reasons to have to lock and pin the metapage for every such
+operation.  Instead, we retain a cached copy of the metapage in each backend's
+relcache entry.  This will produce the correct bucket mapping as long as the
+target bucket hasn't been split since the last cache refresh.
 
 To guard against the possibility that such a split has occurred, the
 primary page of each bucket chain stores the number of buckets that


[parent: 5278222853ca]