mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-09 08:10:09 +08:00
691e8b2e18
The data types that contrib/pageinspect's bt_metap() function were declared to return as OUT arguments were wrong in some cases. For example, the oldest_xact column (a TransactionId/xid field) was declared integer/int4 within the pageinspect extension's sql file. This led to errors when an oldest_xact value that exceeded 2^31-1 was encountered. Some of the other columns were defined incorrectly ever since pageinspect was first introduced, though they were far less likely to produce problems in practice. Fix these issues by changing the declaration of bt_metap() to consistently use data types that can reliably represent all possible values. This fixes things on HEAD only. No backpatch, since it doesn't seem like there is a safe way to fix the issue without including a new version of the pageinspect extension (HEAD/Postgres 13 already introduced a new version of the extension). Besides, the oldest_xact issue has been around since the release of Postgres 11, and we haven't heard any complaints about it before now. Also, throw an error when we detect a bt_metap() declaration that must be from an old version of the pageinspect extension by examining the number of attributes from the tuple descriptor for the return tuples. It seems better to throw an error in a reliable and obvious way following a Postgres upgrade, rather than letting bt_metap() fail unpredictably. The problem is fundamentally with the CREATE FUNCTION declared data types themselves, so I see no sensible alternative. Reported-By: Victor Yegorov Bug: #16285 Discussion: https://postgr.es/m/16285-df8fc1000ab3d5fc@postgresql.org |
||
---|---|---|
.. | ||
adminpack | ||
amcheck | ||
auth_delay | ||
auto_explain | ||
bloom | ||
bool_plperl | ||
btree_gin | ||
btree_gist | ||
citext | ||
cube | ||
dblink | ||
dict_int | ||
dict_xsyn | ||
earthdistance | ||
file_fdw | ||
fuzzystrmatch | ||
hstore | ||
hstore_plperl | ||
hstore_plpython | ||
intagg | ||
intarray | ||
isn | ||
jsonb_plperl | ||
jsonb_plpython | ||
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.