pgsql: hash: Increase the number of possible overflow bitmaps by 8x.

hash: Increase the number of possible overflow bitmaps by 8x.

Per a report from AP, it's not that hard to exhaust the supply of
bitmap pages if you create a table with a hash index and then insert a
few billion rows - and then you start getting errors when you try to
insert additional rows. In the particular case reported by AP,
there's another fix that we can make to improve recycling of overflow
pages, which is another way to avoid the error, but there may be other
cases where this problem happens and that fix won't help. So let's
buy ourselves as much headroom as we can without rearchitecting
anything.

The comments claim that the old limit was 64GB, but it was really
only 32GB, because we didn't use all the bits in the page for bitmap
bits - only the largest power of 2 that could fit after deducting
space for the page header and so forth. Thus, we have 4kB per page
for bitmap bits, not 8kB. The new limit is thus actually 8 times the
old *real* limit but only 4 times the old *purported* limit.

Since this breaks on-disk compatibility, bump HASH_VERSION. We've
already done this earlier in this release cycle, so this doesn't cause
any incremental inconvenience for people using pg_upgrade from
releases prior to v10. However, users who use pg_upgrade to reach
10beta3 or later from 10beta2 or earlier will need to REINDEX any hash
indexes again.

Amit Kapila and Robert Haas

Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/620b49a16d2a16ce6f9edf072a88111f981919d0

Modified Files
--------------
contrib/pageinspect/expected/hash.out | 6 +++---
contrib/pgstattuple/expected/pgstattuple.out | 4 ++--
doc/src/sgml/pageinspect.sgml | 13 +++++++++----
doc/src/sgml/pgstattuple.sgml | 2 +-
src/include/access/hash.h | 9 ++++-----
5 files changed, 19 insertions(+), 15 deletions(-)