Another assert failure from no-palloc-in-critical-sections

I tried the test case given in
http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squirrel@webmail.xs4all.nl
on HEAD. It asserted here:

#2 0x000000000077b419 in ExceptionalCondition (
conditionName=<value optimized out>, errorType=<value optimized out>,
fileName=<value optimized out>, lineNumber=<value optimized out>)
at assert.c:54
#3 0x000000000079be76 in palloc (size=384) at mcxt.c:670
#4 0x0000000000479408 in ginCompressPostingList (ipd=0x7f13343bb048,
nipd=272428, maxsize=384, nwritten=0x7fff1d832eec) at ginpostinglist.c:191
#5 0x000000000046b92b in createPostingTree (index=0x7f1348ae31e0,
items=0x7f13343bb048, nitems=272428, buildStats=0x7fff1d835670)
at gindatapage.c:1739
#6 0x0000000000465206 in buildFreshLeafTuple (ginstate=0x7fff1d8330b0,
attnum=1, key=2105441, category=0 '\000', items=0x7f13343bb048,
nitem=272428, buildStats=0x7fff1d835670) at gininsert.c:158
#7 ginEntryInsert (ginstate=0x7fff1d8330b0, attnum=1, key=2105441,
category=0 '\000', items=0x7f13343bb048, nitem=272428,
buildStats=0x7fff1d835670) at gininsert.c:228
#8 0x0000000000465863 in ginbuild (fcinfo=<value optimized out>)
at gininsert.c:408
#9 0x0000000000784654 in OidFunctionCall3Coll (
functionId=<value optimized out>, collation=0, arg1=139720800461152,
arg2=139720800481760, arg3=31056056) at fmgr.c:1650
#10 0x00000000004f18ba in index_build (heapRelation=0x7f1348ade160,
indexRelation=0x7f1348ae31e0, indexInfo=0x1d9e0b8, isprimary=0 '\000',
isreindex=0 '\000') at index.c:1962

regards, tom lane

On 04/05/2014 08:08 PM, Tom Lane wrote:
> I tried the test case given in
> http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squirrel@webmail.xs4all.nl
> on HEAD. It asserted here:
>...
> #5 0x000000000046b92b in createPostingTree (index=0x7f1348ae31e0,
> items=0x7f13343bb048, nitems=272428, buildStats=0x7fff1d835670)
> at gindatapage.c:1739

Yep, that's a clear violation of the no-pallocs-in-critical-section
rule. Thanks, fixed.

I'm surprised none of the existing regression tests caught that.
Apparently none of them create a GIN index with enough duplicate keys
that it would create a posting tree. I added one.

- Heikki

Heikki Linnakangas wrote:

> I'm surprised none of the existing regression tests caught that.
> Apparently none of them create a GIN index with enough duplicate
> keys that it would create a posting tree. I added one.

Perhaps the --enable-coverage option to configure, and related make
targets, could prove insightful.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services