[David Geier <geidav.pg@gmail.com>]

Hi hackers!

Attached patch fixes a repetition in the user-facing hash index
documentation and the README.

--
David Geier

Attachments:

0001-Fix-hash-index-documentation.patch (text/x-patch, 1.9K) download
From 6420ef7f24f150c88110343634758ae8fb3a779d Mon Sep 17 00:00:00 2001
From: David Geier <geidav.pg@gmail.com>
Date: Mon, 8 Dec 2025 20:37:02 +0100
Subject: [PATCH] Fix hash index documentation

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

diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml
index 9e69ef91fe8..5bb280af71d 100644
--- a/doc/src/sgml/hash.sgml
+++ b/doc/src/sgml/hash.sgml
@@ -125,7 +125,7 @@
   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
+  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
diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README
index 13dc59c124a..8187d20452f 100644
--- a/src/backend/access/hash/README
+++ b/src/backend/access/hash/README
@@ -171,7 +171,7 @@ 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
+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
-- 
2.51.0