Re: PANIC in GIN code
От | Heikki Linnakangas |
---|---|
Тема | Re: PANIC in GIN code |
Дата | |
Msg-id | 558D9CB2.8000305@iki.fi обсуждение исходный текст |
Ответ на | PANIC in GIN code (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: PANIC in GIN code
|
Список | pgsql-hackers |
On 06/26/2015 08:02 PM, Jeff Janes wrote: > 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 Here's a theory: First of all, you have checksums or wal_log_hints enabled. The page is being split (that's evident from "info=48" above). ginPlaceToPage calls GinNewBuffer, which calls GetFreeIndexPage(). That finds a page that can be recycled, and marks it as used. RecordUsedIndexPage calls MarkBufferDirtyHint(), which in turn calls XLogSaveBufferForHint() to create a full-page image record of the page. That calls XLogBeginInsert() + XLogInsert(), and leaves the begininsert_called == false. If you had assertions enabled, you'd see the assertion in XLogBeginInsert() to fail. I'll look into that over the weekend.. - Heikki
В списке pgsql-hackers по дате отправления: