postgresql/contrib/pageinspect/pageinspect--1.7--1.8.sql

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

70 lines
1.7 KiB
MySQL
Raw Normal View History

/* contrib/pageinspect/pageinspect--1.7--1.8.sql */
-- complain if script is sourced in psql, rather than via ALTER EXTENSION
\echo Use "ALTER EXTENSION pageinspect UPDATE TO '1.8'" to load this file. \quit
--
-- heap_tuple_infomask_flags()
--
CREATE FUNCTION heap_tuple_infomask_flags(
t_infomask integer,
t_infomask2 integer,
raw_flags OUT text[],
combined_flags OUT text[])
RETURNS record
AS 'MODULE_PATHNAME', 'heap_tuple_infomask_flags'
LANGUAGE C STRICT PARALLEL SAFE;
--
-- bt_metap()
--
DROP FUNCTION bt_metap(text);
CREATE FUNCTION bt_metap(IN relname text,
OUT magic int4,
OUT version int4,
pageinspect: Fix types used for bt_metap() columns. 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
2020-03-08 01:44:53 +01:00
OUT root int8,
OUT level int8,
OUT fastroot int8,
OUT fastlevel int8,
OUT oldest_xact xid,
OUT last_cleanup_num_tuples float8,
OUT allequalimage boolean)
AS 'MODULE_PATHNAME', 'bt_metap'
LANGUAGE C STRICT PARALLEL SAFE;
--
-- bt_page_items(text, int4)
--
DROP FUNCTION bt_page_items(text, int4);
CREATE FUNCTION bt_page_items(IN relname text, IN blkno int4,
OUT itemoffset smallint,
OUT ctid tid,
OUT itemlen smallint,
OUT nulls bool,
OUT vars bool,
OUT data text,
OUT dead boolean,
OUT htid tid,
OUT tids tid[])
RETURNS SETOF record
AS 'MODULE_PATHNAME', 'bt_page_items'
LANGUAGE C STRICT PARALLEL SAFE;
--
-- bt_page_items(bytea)
--
DROP FUNCTION bt_page_items(bytea);
CREATE FUNCTION bt_page_items(IN page bytea,
OUT itemoffset smallint,
OUT ctid tid,
OUT itemlen smallint,
OUT nulls bool,
OUT vars bool,
OUT data text,
OUT dead boolean,
OUT htid tid,
OUT tids tid[])
RETURNS SETOF record
AS 'MODULE_PATHNAME', 'bt_page_items_bytea'
LANGUAGE C STRICT PARALLEL SAFE;