From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PANIC in GIN code |
Date: | 2015-06-26 18:40:50 |
Message-ID: | 558D9CB2.8000305@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-06-26 18:46:47 | Re: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? |
Previous Message | Peter Geoghegan | 2015-06-26 18:37:23 | Re: 9.5 release notes |