Re: Unexpected behavior after OOM errors - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Unexpected behavior after OOM errors
Date
Msg-id 91199.1784569717@localhost
Whole thread
In response to Re: Unexpected behavior after OOM errors  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Unexpected behavior after OOM errors
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> 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>)
atexecTuples.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



pgsql-hackers by date:

Previous
From: Nitin Motiani
Date:
Subject: [PATCH v1] Fix propagation of indimmediate flag in index_create_copy
Next
From: Matthias van de Meent
Date:
Subject: Re: Unexpected behavior after OOM errors