Michael Paquier <[email protected]> wrote:

> On Fri, Jul 17, 2026 at 12:00:01PM +0300, Alexander Lakhin wrote:
> > 4) make_new_heap():
> > --- a/src/backend/commands/repack.c
> > +++ b/src/backend/commands/repack.c
> > @@ -1255,3 +1255,5 @@ make_new_heap(Oid OIDOldHeap, Oid NewTableSpace, Oid 
> > NewAccessMethod,
> >       */
> > +oom_prob = 0.01;
> >      CommandCounterIncrement();
> > +oom_prob = 0;
> > 
> > triggers:
> > TRAP: failed Assert("ItemIdIsNormal(lp)"), File: "heapam.c", Line: 2813, 
> > PID: 943626
> > also:
> > ERROR:  attempted to delete invisible tuple
> 
> I'll let Alvaro comment on this one.  It deserves an open item.

I was also curious because I worked on repack.c recently. After applying (a
bit rebased) random-oom-errors.patch from [1] and after turning some "out of
memory" errors to PANIC, I could reproduce the error even on PG 18. The stack
trace is below. So it does not seem to be PG 19 specific.

#3  0x0000000000c1837a in errfinish (filename=0xee1d80 "mcxt.c", lineno=1164, 
funcname=0xee24a0 <__func__.6> "MemoryContextAllocationFailure") at elog.c:600
#4  0x0000000000c58e0c in MemoryContextAllocationFailure (context=0x2fb3a60, 
size=344, flags=0) at mcxt.c:1164
#5  0x0000000000c4bc1e in AllocSetAlloc (context=0x2fb3a60, size=344, flags=0) 
at aset.c:983
#6  0x0000000000c59504 in palloc0 (size=344) at mcxt.c:1388
#7  0x00000000007898a8 in MakeTupleTableSlot (tupleDesc=0x7f3eef0aa228, 
tts_ops=0xdfddc0 <TTSOpsBufferHeapTuple>) at execTuples.c:1321
#8  0x0000000000789b76 in MakeSingleTupleTableSlot (tupdesc=0x7f3eef0aa228, 
tts_ops=0xdfddc0 <TTSOpsBufferHeapTuple>) at execTuples.c:1430
#9  0x00000000005712a0 in table_slot_create (relation=0x7f3eef0a9f08, 
reglist=0x0) at tableam.c:98
#10 0x000000000052a812 in systable_beginscan (heapRelation=0x7f3eef0a9f08, 
indexId=2659, indexOK=true, snapshot=0x0, nkeys=2, key=0x7fffa5230e00) at 
genam.c:408
#11 0x0000000000c028dc in RelationBuildTupleDesc (relation=0x7f3eef091378) at 
relcache.c:564
#12 0x0000000000c03ad5 in RelationBuildDesc (targetRelId=32768, insertIt=false) 
at relcache.c:1206
#13 0x0000000000c05ffa in RelationRebuildRelation (relation=0x7f3eef08f1b8) at 
relcache.c:2661
#14 0x0000000000c06671 in RelationFlushRelation (relation=0x7f3eef08f1b8) at 
relcache.c:2847
#15 0x0000000000c06864 in RelationCacheInvalidateEntry (relationId=32768) at 
relcache.c:2949
#16 0x0000000000bf6f7b in LocalExecuteInvalidationMessage (msg=0x30898d0) at 
inval.c:856
#17 0x0000000000bf6908 in ProcessInvalidationMessages (group=0x30895d0, 
func=0xbf6e6f <LocalExecuteInvalidationMessage>) at inval.c:578
#18 0x0000000000bf7ac4 in CommandEndInvalidationMessages () at inval.c:1419
#19 0x000000000058b462 in AtCCI_LocalCache () at xact.c:1591
#20 0x000000000058adef in CommandCounterIncrement () at xact.c:1139
#21 0x0000000000699f03 in make_new_heap (OIDOldHeap=16384, NewTableSpace=0, 
NewAccessMethod=2, relpersistence=112 'p', lockmode=0) at cluster.c:788
#22 0x0000000000699bca in rebuild_relation (OldHeap=0x7f3eef08e998, 
index=0x7f3eef08ec88, verbose=false) at cluster.c:659
#23 0x0000000000699624 in cluster_rel (OldHeap=0x7f3eef08e998, indexOid=16388, 
params=0x7fffa52314d4) at cluster.c:472

[1] 
https://www.postgresql.org/message-id/95c64dc2-3abe-4f4e-b285-4c681f565d9f%40gmail.com

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com


Reply via email to