database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

pg_surgery: Fix infinite loop on large TID arrays

Browse Source 
heap_force_common() tracked the current position in the caller-supplied
tid[] using OffsetNumber, which is only 16 bits wide, so when the array
held more than 65535 entries, the updated index wrapped around and the
outer loop never reached the exit condition.  A SQL call with a
sufficiently large TID array would then run until interrupted.

Fix by tracking the tid[] position using int instead of OffsetNumber.
A regress case based on the report is included.

Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reported-by: Yuelin Wang <1217816127@qq.com>
Backpatch-through: 14
Bug: #19607
Discussion: https://postgr.es/m/19607-2f256a66481c514b@postgresql.org
This commit is contained in:
Álvaro Herrera
2026-08-04 11:44:11 +02:00
parent 18006c1bd6
commit 1b6c99d96a
3 changed files with 28 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
contrib/pg_surgery/expected/heap_surgery.out
View File

@@ -134,6 +134,23 @@ select heap_force_kill('htab2'::regclass, ARRAY['(0, 3)']::tid[]);
(1 row)
-- a tid[] larger than 65535 entries must still finish
create temp table htab3(a int);
insert into htab3 values (1);
select heap_force_kill(
'htab3'::regclass,
array(select '(0,1)'::tid from generate_series(1, 65536)));
heap_force_kill
-----------------
(1 row)
select count(*) from htab3;
count
-------
0
(1 row)
-- materialized view.
-- note that we don't commit the transaction, so autovacuum can't interfere.
begin;

6
contrib/pg_surgery/heap_surgery.c
View File

@@ -41,7 +41,7 @@ static Datum heap_force_common(FunctionCallInfo fcinfo,
HeapTupleForceOption heap_force_opt);
static void sanity_check_tid_array(ArrayType *ta, int *ntids);
static BlockNumber find_tids_one_page(ItemPointer tids, int ntids,
OffsetNumber *next_start_ptr);
int *next_start_ptr);
/*-------------------------------------------------------------------------
* heap_force_kill()
@@ -88,7 +88,7 @@ heap_force_common(FunctionCallInfo fcinfo, HeapTupleForceOption heap_force_opt)
int ntids,
nblocks;
Relation rel;
OffsetNumber curr_start_ptr,
int curr_start_ptr,
next_start_ptr;
bool include_this_tid[MaxHeapTuplesPerPage];
@@ -410,7 +410,7 @@ sanity_check_tid_array(ArrayType *ta, int *ntids)
* ------------------------------------------------------------------------
*/
static BlockNumber
find_tids_one_page(ItemPointer tids, int ntids, OffsetNumber *next_start_ptr)
find_tids_one_page(ItemPointer tids, int ntids, int *next_start_ptr)
{
int i;
BlockNumber prev_blkno,

8
contrib/pg_surgery/sql/heap_surgery.sql
View File

@@ -65,6 +65,14 @@ select heap_force_kill('htab2'::regclass, ARRAY[NULL]::tid[]);
-- but we should be able to kill the one tuple we have
select heap_force_kill('htab2'::regclass, ARRAY['(0, 3)']::tid[]);
-- a tid[] larger than 65535 entries must still finish
create temp table htab3(a int);
insert into htab3 values (1);
select heap_force_kill(
'htab3'::regclass,
array(select '(0,1)'::tid from generate_series(1, 65536)));
select count(*) from htab3;
-- materialized view.
-- note that we don't commit the transaction, so autovacuum can't interfere.
begin;