Cosmetic fixes for hash index write-ahead logging.

Amit Kapila.  One of these was reported by Tom Lane.

Discussion: http://postgr.es/m/5515.1489514099@sss.pgh.pa.us

diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README
index 00beb86ffaeaefe485f4e0e8ad01e5513e3f42dc..53b0e0def1536bf670470a9d498b7c9e0fec2d2f 100644 (file)
--- a/src/backend/access/hash/README
+++ b/src/backend/access/hash/README
@@ -365,9 +365,6 @@ try to split the bucket again until the prior split is finished.  In other
 words, a bucket can be in the middle of being split for some time, but it can't
 be in the middle of two splits at the same time.
 
-Although we can survive a failure to split a bucket, a crash is likely to
-corrupt the index, since hash indexes are not yet WAL-logged.
-
 The fourth operation is garbage collection (bulk deletion):
 
    next bucket := 0

diff --git a/src/backend/access/hash/hashpage.c b/src/backend/access/hash/hashpage.c
index dc606f162e1ca357c408a5aa5069286ac8125b37..622cc4b837da1b3ae5ea3d6e46ec44e9daa3d479 100644 (file)
--- a/src/backend/access/hash/hashpage.c
+++ b/src/backend/access/hash/hashpage.c
@@ -975,7 +975,7 @@ fail:
  * hash indexes sequentially anyway, that probably doesn't matter.
  *
  * XXX It's annoying that this code is executed with the metapage lock held.
- * We need to interlock against _hash_getovflpage() adding a new overflow page
+ * We need to interlock against _hash_addovflpage() adding a new overflow page
  * concurrently, but it'd likely be better to use LockRelationForExtension
  * for the purpose.  OTOH, adding a splitpoint is a very infrequent operation,
  * so it may not be worth worrying about.