On 2024-Aug-16, Marcin Barczyński wrote:
> REINDEX INDEX pg_catalog.pg_default_acl_role_nsp_obj_index got stuck
> waiting for a transaction from the future in PG 13.16. Below is some
> additional data that I was able to gather.
Hmm, that's odd.
> #3 XactLockTableWait (xid=2004, rel=<optimized out>, ctid=<optimized
> out>, oper=XLTW_InsertIndexUnique) at storage/lmgr/lmgr.c:690
> #4 0x000000000054b44b in heapam_index_build_range_scan
> (heapRelation=0x7f86ca209a38, indexRelation=0x7f86ca20a5f8,
> indexInfo=0x10cd008, allow_sync=<optimized out>, anyvisible=false,
> progress=true,
> start_blockno=0, numblocks=4294967295, callback=0x568530
> <_bt_build_callback>, callback_state=0x7fffd823c3b0, scan=0x10ca408)
> at access/heap/heapam_handler.c:1552
This means it wants to wait for transaction with xid=2004 for some
reason. But why? Line 1552 in heapam_handler.c in 13.16 is inside the
HEAPTUPLE_DELETE_IN_PROGRESS case of HeapTupleSatisfiesVacuum, and the
xwait has been obtained by HeapTupleHeaderGetUpdateXid. The three
distinct t_infomask values in the page you should are 0x0502, 0x2102,
0x2502; neither of them has HEAP_XMAX_IS_MULTI set (0x1000), which means
the value must be a literal value in the t_xmax field, and there's no
such value in the page you show. So something does not square here.
Also, the ip_posid value says to look for a tuple with lp=13, but
there's no such per pageinspect. I think you have get_raw_page'd the
wrong page. Maybe do a "bt full" in gdb to see the values of the
locals.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
