2021-01-13 19:57:21 +01:00
|
|
|
-- The gist_page_opaque_info() function prints the page's LSN. Normally,
|
|
|
|
-- that's constant 1 (GistBuildLSN) on every page of a freshly built GiST
|
|
|
|
-- index. But with wal_level=minimal, the whole relation is dumped to WAL at
|
|
|
|
-- the end of the transaction if it's smaller than wal_skip_threshold, which
|
|
|
|
-- updates the LSNs. Wrap the tests on gist_page_opaque_info() in the
|
|
|
|
-- same transaction with the CREATE INDEX so that we see the LSNs before
|
|
|
|
-- they are possibly overwritten at end of transaction.
|
|
|
|
BEGIN;
|
|
|
|
-- Create a test table and GiST index.
|
2021-01-13 09:33:33 +01:00
|
|
|
CREATE TABLE test_gist AS SELECT point(i,i) p, i::text t FROM
|
|
|
|
generate_series(1,1000) i;
|
|
|
|
CREATE INDEX test_gist_idx ON test_gist USING gist (p);
|
|
|
|
-- Page 0 is the root, the rest are leaf pages
|
|
|
|
SELECT * FROM gist_page_opaque_info(get_raw_page('test_gist_idx', 0));
|
|
|
|
lsn | nsn | rightlink | flags
|
|
|
|
-----+-----+------------+-------
|
|
|
|
0/1 | 0/0 | 4294967295 | {}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM gist_page_opaque_info(get_raw_page('test_gist_idx', 1));
|
|
|
|
lsn | nsn | rightlink | flags
|
|
|
|
-----+-----+------------+--------
|
|
|
|
0/1 | 0/0 | 4294967295 | {leaf}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM gist_page_opaque_info(get_raw_page('test_gist_idx', 2));
|
|
|
|
lsn | nsn | rightlink | flags
|
|
|
|
-----+-----+-----------+--------
|
|
|
|
0/1 | 0/0 | 1 | {leaf}
|
|
|
|
(1 row)
|
|
|
|
|
2021-01-13 19:57:21 +01:00
|
|
|
COMMIT;
|
2021-01-13 09:33:33 +01:00
|
|
|
SELECT * FROM gist_page_items(get_raw_page('test_gist_idx', 0), 'test_gist_idx');
|
2021-02-15 05:11:11 +01:00
|
|
|
itemoffset | ctid | itemlen | dead | keys
|
|
|
|
------------+-----------+---------+------+-------------------
|
2022-02-07 21:20:42 +01:00
|
|
|
1 | (1,65535) | 40 | f | (p)=((185,185))
|
|
|
|
2 | (2,65535) | 40 | f | (p)=((370,370))
|
|
|
|
3 | (3,65535) | 40 | f | (p)=((555,555))
|
|
|
|
4 | (4,65535) | 40 | f | (p)=((740,740))
|
|
|
|
5 | (5,65535) | 40 | f | (p)=((870,870))
|
|
|
|
6 | (6,65535) | 40 | f | (p)=((1000,1000))
|
|
|
|
(6 rows)
|
2021-01-13 09:33:33 +01:00
|
|
|
|
|
|
|
SELECT * FROM gist_page_items(get_raw_page('test_gist_idx', 1), 'test_gist_idx') LIMIT 5;
|
2021-02-15 05:11:11 +01:00
|
|
|
itemoffset | ctid | itemlen | dead | keys
|
|
|
|
------------+-------+---------+------+-------------
|
|
|
|
1 | (0,1) | 40 | f | (p)=((1,1))
|
|
|
|
2 | (0,2) | 40 | f | (p)=((2,2))
|
|
|
|
3 | (0,3) | 40 | f | (p)=((3,3))
|
|
|
|
4 | (0,4) | 40 | f | (p)=((4,4))
|
|
|
|
5 | (0,5) | 40 | f | (p)=((5,5))
|
2021-01-13 09:33:33 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2021-01-13 11:32:54 +01:00
|
|
|
-- gist_page_items_bytea prints the raw key data as a bytea. The output of that is
|
2022-03-15 03:29:23 +01:00
|
|
|
-- platform-dependent (endianness), so omit the actual key data from the output.
|
2021-01-13 11:32:54 +01:00
|
|
|
SELECT itemoffset, ctid, itemlen FROM gist_page_items_bytea(get_raw_page('test_gist_idx', 0));
|
|
|
|
itemoffset | ctid | itemlen
|
|
|
|
------------+-----------+---------
|
|
|
|
1 | (1,65535) | 40
|
|
|
|
2 | (2,65535) | 40
|
|
|
|
3 | (3,65535) | 40
|
|
|
|
4 | (4,65535) | 40
|
|
|
|
5 | (5,65535) | 40
|
|
|
|
6 | (6,65535) | 40
|
2022-02-07 21:20:42 +01:00
|
|
|
(6 rows)
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2023-03-02 06:03:08 +01:00
|
|
|
-- Suppress the DETAIL message, to allow the tests to work across various
|
|
|
|
-- page sizes and architectures.
|
|
|
|
\set VERBOSITY terse
|
|
|
|
-- Failures with non-GiST index.
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
CREATE INDEX test_gist_btree on test_gist(t);
|
|
|
|
SELECT gist_page_items(get_raw_page('test_gist_btree', 0), 'test_gist_btree');
|
|
|
|
ERROR: "test_gist_btree" is not a GiST index
|
2023-03-02 06:03:08 +01:00
|
|
|
SELECT gist_page_items(get_raw_page('test_gist_btree', 0), 'test_gist_idx');
|
|
|
|
ERROR: input page is not a valid GiST page
|
pageinspect: Add more sanity checks to prevent out-of-bound reads
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-03-27 10:53:40 +02:00
|
|
|
-- Failure with various modes.
|
|
|
|
-- invalid page size
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
SELECT gist_page_items_bytea('aaa'::bytea);
|
|
|
|
ERROR: invalid page size
|
|
|
|
SELECT gist_page_items('aaa'::bytea, 'test_gist_idx'::regclass);
|
|
|
|
ERROR: invalid page size
|
|
|
|
SELECT gist_page_opaque_info('aaa'::bytea);
|
|
|
|
ERROR: invalid page size
|
pageinspect: Add more sanity checks to prevent out-of-bound reads
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-03-27 10:53:40 +02:00
|
|
|
-- invalid special area size
|
|
|
|
SELECT * FROM gist_page_opaque_info(get_raw_page('test_gist', 0));
|
|
|
|
ERROR: input page is not a valid GiST page
|
|
|
|
SELECT gist_page_items_bytea(get_raw_page('test_gist', 0));
|
|
|
|
ERROR: input page is not a valid GiST page
|
|
|
|
SELECT gist_page_items_bytea(get_raw_page('test_gist_btree', 0));
|
|
|
|
ERROR: input page is not a valid GiST page
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
\set VERBOSITY default
|
pageinspect: Fix handling of all-zero pages
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-04-14 08:08:03 +02:00
|
|
|
-- Tests with all-zero pages.
|
|
|
|
SHOW block_size \gset
|
|
|
|
SELECT gist_page_items_bytea(decode(repeat('00', :block_size), 'hex'));
|
|
|
|
gist_page_items_bytea
|
|
|
|
-----------------------
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SELECT gist_page_items(decode(repeat('00', :block_size), 'hex'), 'test_gist_idx'::regclass);
|
|
|
|
gist_page_items
|
|
|
|
-----------------
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SELECT gist_page_opaque_info(decode(repeat('00', :block_size), 'hex'));
|
|
|
|
gist_page_opaque_info
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
2021-01-13 09:33:33 +01:00
|
|
|
DROP TABLE test_gist;
|