Hi hackers!
Attached patch fixes a repetition in the user-facing hash index
documentation and the README.
--
David Geier
From 6420ef7f24f150c88110343634758ae8fb3a779d Mon Sep 17 00:00:00 2001
From: David Geier <[email protected]>
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
