Skip to content

Commit f7b711c

Browse files
committed
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
1 parent aefeb68 commit f7b711c

File tree

2 files changed

+1
-4
lines changed

2 files changed

+1
-4
lines changed

src/backend/access/hash/README

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -365,9 +365,6 @@ try to split the bucket again until the prior split is finished. In other
365365
words, a bucket can be in the middle of being split for some time, but it can't
366366
be in the middle of two splits at the same time.
367367

368-
Although we can survive a failure to split a bucket, a crash is likely to
369-
corrupt the index, since hash indexes are not yet WAL-logged.
370-
371368
The fourth operation is garbage collection (bulk deletion):
372369

373370
next bucket := 0

src/backend/access/hash/hashpage.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -975,7 +975,7 @@ _hash_expandtable(Relation rel, Buffer metabuf)
975975
* hash indexes sequentially anyway, that probably doesn't matter.
976976
*
977977
* XXX It's annoying that this code is executed with the metapage lock held.
978-
* We need to interlock against _hash_getovflpage() adding a new overflow page
978+
* We need to interlock against _hash_addovflpage() adding a new overflow page
979979
* concurrently, but it'd likely be better to use LockRelationForExtension
980980
* for the purpose. OTOH, adding a splitpoint is a very infrequent operation,
981981
* so it may not be worth worrying about.

0 commit comments

Comments
 (0)