620b49a16d
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 |
||
---|---|---|
.. | ||
adminpack | ||
amcheck | ||
auth_delay | ||
auto_explain | ||
bloom | ||
btree_gin | ||
btree_gist | ||
chkpass | ||
citext | ||
cube | ||
dblink | ||
dict_int | ||
dict_xsyn | ||
earthdistance | ||
file_fdw | ||
fuzzystrmatch | ||
hstore | ||
hstore_plperl | ||
hstore_plpython | ||
intagg | ||
intarray | ||
isn | ||
lo | ||
ltree | ||
ltree_plpython | ||
oid2name | ||
pageinspect | ||
passwordcheck | ||
pg_buffercache | ||
pg_freespacemap | ||
pg_prewarm | ||
pg_standby | ||
pg_stat_statements | ||
pg_trgm | ||
pg_visibility | ||
pgcrypto | ||
pgrowlocks | ||
pgstattuple | ||
postgres_fdw | ||
seg | ||
sepgsql | ||
spi | ||
sslinfo | ||
start-scripts | ||
tablefunc | ||
tcn | ||
test_decoding | ||
tsm_system_rows | ||
tsm_system_time | ||
unaccent | ||
uuid-ossp | ||
vacuumlo | ||
xml2 | ||
contrib-global.mk | ||
Makefile | ||
README |
The PostgreSQL contrib tree --------------------------- This subtree contains porting tools, analysis utilities, and plug-in features that are not part of the core PostgreSQL system, mainly because they address a limited audience or are too experimental to be part of the main source tree. This does not preclude their usefulness. User documentation for each module appears in the main SGML documentation. When building from the source distribution, these modules are not built automatically, unless you build the "world" target. You can also build and install them all by running "make all" and "make install" in this directory; or to build and install just one selected module, do the same in that module's subdirectory. Some directories supply new user-defined functions, operators, or types. To make use of one of these modules, after you have installed the code you need to register the new SQL objects in the database system by executing a CREATE EXTENSION command. In a fresh database, you can simply do CREATE EXTENSION module_name; See the PostgreSQL documentation for more information about this procedure.