BUG #17741: vacuum process hangs after pg_surgery manipulations - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      17741
Logged by:          Alexander Kozhemyakin
Email address:      a.kozhemyakin@postgrespro.ru
PostgreSQL version: 15.1
Operating system:   Debian 10 (x86_64)
Description:

On the REL_15_STABLE, you can hang vacuum freeze. Maybe this is not
desired?
https://www.postgresql.org/docs/current/pgsurgery.html

reproduce script:
create extension pg_surgery;
create table t1(a int);
insert into t1 values (1);
update t1 set a = 2;
select heap_force_kill('t1'::regclass, ARRAY['(0, 1)']::tid[]);
select ctid from t1;
update t1 set a = 3;
select ctid from t1;
vacuum freeze t1;

Now we have hung vacuum process.
stacktrace:
#0  0x0000561b89170515 in heap_prune_chain (prstate=0x7ffd243a8fb0,
rootoffnum=2, buffer=129) at pruneheap.c:615
#1  heap_page_prune (relation=relation@entry=0x7fd14fa3cba8,
buffer=buffer@entry=129, vistest=<optimized out>,
old_snap_xmin=old_snap_xmin@entry=0, old_snap_ts=old_snap_ts@entry=0,
nnewlpdead=nnewlpdead@entry=0x7ffd243a9c04, off_loc=0x561b8ae3f87c)
    at pruneheap.c:376
#2  0x0000561b89172757 in lazy_scan_prune
(vacrel=vacrel@entry=0x561b8ae3f7f8, buf=buf@entry=129, blkno=blkno@entry=0,
page=page@entry=0x7fd1503abc00 "",
prunestate=prunestate@entry=0x7ffd243aaeb0) at vacuumlazy.c:1590
#3  0x0000561b8917451b in lazy_scan_heap (vacrel=0x561b8ae3f7f8) at
vacuumlazy.c:1048
#4  heap_vacuum_rel (rel=0x7fd14fa3cba8, params=0x7ffd243ab360,
bstrategy=<optimized out>) at vacuumlazy.c:534
#5  0x0000561b8929d1bb in table_relation_vacuum (bstrategy=<optimized out>,
params=0x7ffd243ab360, rel=0x7fd14fa3cba8) at
../../../src/include/access/tableam.h:1680
#6  vacuum_rel (relid=24576, relation=<optimized out>,
params=params@entry=0x7ffd243ab360) at vacuum.c:2086
#7  0x0000561b8929e6f5 in vacuum (relations=0x561b8aee6668,
params=0x7ffd243ab360, bstrategy=<optimized out>, isTopLevel=<optimized
out>) at vacuum.c:475
#8  0x0000561b8929ec1f in ExecVacuum (pstate=pstate@entry=0x561b8aedbae8,
vacstmt=vacstmt@entry=0x561b8ae1a268, isTopLevel=isTopLevel@entry=true) at
vacuum.c:275
#9  0x0000561b8940c3d0 in standard_ProcessUtility (pstmt=0x561b8ae1a628,
queryString=0x561b8ae197b8 "vacuum freeze t1;", readOnlyTree=<optimized
out>, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x561b8ae1a708, qc=0x7ffd243ab6b0)
    at utility.c:866
#10 0x0000561b8940ab3f in PortalRunUtility
(portal=portal@entry=0x561b8ae87018, pstmt=pstmt@entry=0x561b8ae1a628,
isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false, dest=0x561b8ae1a708,
qc=0x7ffd243ab6b0) at pquery.c:1158
#11 0x0000561b8940ac73 in PortalRunMulti
(portal=portal@entry=0x561b8ae87018, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x561b8ae1a708,
altdest=altdest@entry=0x561b8ae1a708, qc=qc@entry=0x7ffd243ab6b0)
    at pquery.c:1315
#12 0x0000561b8940b17f in PortalRun (portal=portal@entry=0x561b8ae87018,
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true,
run_once=run_once@entry=true, dest=dest@entry=0x561b8ae1a708,
altdest=altdest@entry=0x561b8ae1a708,
    qc=0x7ffd243ab6b0) at pquery.c:791
#13 0x0000561b89407763 in exec_simple_query (query_string=0x561b8ae197b8
"vacuum freeze t1;") at postgres.c:1250
#14 0x0000561b8940840b in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at postgres.c:4593
#15 0x0000561b8938e791 in BackendRun (port=<optimized out>, port=<optimized
out>) at postmaster.c:4504
#16 BackendStartup (port=<optimized out>) at postmaster.c:4232
#17 ServerLoop () at postmaster.c:1806
#18 0x0000561b8938f718 in PostmasterMain (argc=3, argv=0x561b8ae13db0) at
postmaster.c:1478
#19 0x0000561b89123f19 in main (argc=3, argv=0x561b8ae13db0) at main.c:202