1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-15 19:21:59 +03:00

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
This commit is contained in:
Robert Haas
2017-03-15 07:21:17 -04:00
parent aefeb68741
commit f7b711c8bc
2 changed files with 1 additions and 4 deletions

View File

@ -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 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. 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): The fourth operation is garbage collection (bulk deletion):
next bucket := 0 next bucket := 0

View File

@ -975,7 +975,7 @@ fail:
* hash indexes sequentially anyway, that probably doesn't matter. * hash indexes sequentially anyway, that probably doesn't matter.
* *
* XXX It's annoying that this code is executed with the metapage lock held. * 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 * concurrently, but it'd likely be better to use LockRelationForExtension
* for the purpose. OTOH, adding a splitpoint is a very infrequent operation, * for the purpose. OTOH, adding a splitpoint is a very infrequent operation,
* so it may not be worth worrying about. * so it may not be worth worrying about.