| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unexpected behavior after OOM errors |
| Date: | 2026-07-20 17:48:37 |
| Message-ID: | 91199.1784569717@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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>) 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-07-20 18:12:40 | Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks |
| Previous Message | Nitin Motiani | 2026-07-20 17:39:44 | [PATCH v1] Fix propagation of indimmediate flag in index_create_copy |