PANIC in GIN code - Mailing list pgsql-hackers

From Jeff Janes
Subject PANIC in GIN code
Date
Msg-id CAMkU=1xyoT4Dz9t6ijsodjOgJaGD-rLad0WW7Vynw4-Zjqyogw@mail.gmail.com
Whole thread Raw
Responses Re: PANIC in GIN code  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Under high load against f7bb7f0625771bc71869cda, I occasionally get:

PANIC:  XLogBeginInsert was not called

It seems to only come from vacuuming.

Here is an example back-trace:

#0  0x0000003dcb632625 in raise () from /lib64/libc.so.6
#1  0x0000003dcb633e05 in abort () from /lib64/libc.so.6
#2  0x000000000079a39c in errfinish (dummy=<value optimized out>) at elog.c:551
#3  0x000000000079b0e4 in elog_finish (elevel=<value optimized out>, fmt=<value optimized out>) at elog.c:1368
#4  0x00000000004dd1fe in XLogInsert (rmid=13 '\r', info=48 '0') at xloginsert.c:412
#5  0x0000000000478e13 in ginPlaceToPage (btree=0x7fff1fbb7f60, stack=0x2878760, insertdata=<value optimized out>, updateblkno=<value optimized out>,
    childbuf=0, buildStats=<value optimized out>) at ginbtree.c:582
#6  0x0000000000479a33 in ginInsertValue (btree=0x7fff1fbb7f60, stack=0x2878760, insertdata=0x7fff1fbb7fe0, buildStats=0x0) at ginbtree.c:751
#7  0x000000000047364a in ginEntryInsert (ginstate=0x7fff1fbb8280, attnum=54624, key=1, category=<value optimized out>, items=0x287d3c0, nitem=1,
    buildStats=0x0) at gininsert.c:234
#8  0x000000000047ef4b in ginInsertCleanup (ginstate=0x7fff1fbb8280, vac_delay=<value optimized out>, stats=0x2868d90) at ginfast.c:843
#9  0x000000000047e024 in ginbulkdelete (fcinfo=<value optimized out>) at ginvacuum.c:547


From the code, it seems obvious that XLogBeginInsert is getting called at ginbtree.c line 373, so I think that some obscure code path of btree->placeToPage must be either consuming or resetting that XLogBeginInsert before it returns control to ginbtree.c


Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Josh Berkus
Date:
Subject: Re: Support for N synchronous standby servers - take 2