Re: BUG #16162: create index using gist_trgm_ops leads to panic

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, kunert(at)cms(dot)hu-berlin(dot)de, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16162: create index using gist_trgm_ops leads to panic
Date: 2019-12-14 19:00:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Hello Heikki,
14.12.2019 1:02, Heikki Linnakangas wrote:
> Like Tom suspected at [1], the bug was that the parent page got split,
> and the stacked information wasn't updated. The code called
> gistFindCorrectParent(), which should've updated the stack, but that
> function checked the LSN of the page and did nothing if it matched. To
> trigger the bug, you needed to have an insertion that split a page
> into three (or more) pages, and inserting the downlink caused the
> parent page to split, too.
> Committed a fix. Many thanks for the reproducer scripts, Andreas and
> Alexander!
The script that I presented in [0] still reproduces assertion failure
for me on REL_12_STABLE (fd005e1a):

iteration 6
psql:/tmp/test_gist_intarray.sql:2: NOTICE:  extension "intarray"
already exists, skipping
COPY 7000
INSERT 0 7000
INSERT 0 14000
INSERT 0 28000
INSERT 0 56000
psql:/tmp/test_gist_intarray.sql:10: server closed the connection
        This probably means the server terminated abnormally
        before or while processing the request.
psql:/tmp/test_gist_intarray.sql:10: fatal: connection to server was lost

Core was generated by `postgres: law regression [local] CREATE
INDEX                                 '.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f10c0ed4801 in __GI_abort () at abort.c:79
#2  0x000055cfe1d476a6 in ExceptionalCondition (
    conditionName=conditionName(at)entry=0x55cfe1db42a8 "!(((((ItemId)
(&((PageHeader) (page))->pd_linp[(todelete) - 1])))->lp_len != 0))",
errorType=errorType(at)entry=0x55cfe1d9e788 "FailedAssertion",
    fileName=fileName(at)entry=0x55cfe1db4250 "gistutil.c",
lineNumber=lineNumber(at)entry=70) at assert.c:54
#3  0x000055cfe18e3dc0 in gistnospace (page=page(at)entry=0x7f10b8705d00
"", itvec=itvec(at)entry=0x7ffec1b676e0,
    len=len(at)entry=2, todelete=todelete(at)entry=5,
freespace=freespace(at)entry=819) at gistutil.c:70
#4  0x000055cfe18e1301 in gistplacetopage (rel=0x7f10c2006500,
    giststate=giststate(at)entry=0x55cfe3934ec0, buffer=920,
itup=itup(at)entry=0x7ffec1b676e0, ntup=ntup(at)entry=2,
    oldoffnum=5, newblkno=0x0, leftchildbuf=897,
splitinfo=0x7ffec1b67670, markfollowright=true,
    heapRel=0x7f10c20107a0, is_build=true) at gist.c:257
> [1]
> - Heikki
Best regards,

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-12-15 04:48:15 BUG #16166: Caution needs to be expanded
Previous Message Tomas Vondra 2019-12-14 13:39:12 Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash