Re: BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: exclusion(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index
Date: 2024-03-19 12:07:12
Message-ID: CAHewXN=FDqixMYCJXbdmH=P7GPBE_zH0HzQYkdSCxOtP6=VYiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> 于2024年3月17日周日 23:39写道:

> The following bug has been logged on the website:
>
> Bug reference: 18396
> Logged by: Alexander Lakhin
> Email address: exclusion(at)gmail(dot)com
> PostgreSQL version: 16.2
> Operating system: Ubuntu 22.04
> Description:
>
> The following script:
> psql -c "CREATE EXTENSION btree_gist;"
> numclients=50
> for ((i=1;i<=100;i++)); do
> echo "iteration $i"
> for ((c=1;c<=$numclients;c++)); do
> echo "
> CREATE TEMP TABLE t (a text);
> CREATE INDEX idx ON t USING GIST (a);
>
> INSERT INTO t SELECT '' FROM generate_series(1, 500) g;
> INSERT INTO t SELECT
> (SELECT string_agg('text' || g, ' ') FROM generate_series(1, 600) g)
> FROM generate_series(1, 30);
> " | psql >psql-$c.log &
> done
> wait
> grep 'TRAP:' server.log && { res=0; break; }
> done
>
> triggers an assertion failure:
> ...
> iteration 4
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> connection to server was lost
> TRAP: failed Assert("parent->lsn != PageGetLSN(parent->page) || is_build"),
> File: "gist.c", Line: 1050, PID: 789065
>
> with the stack trace:
> #0 __pthread_kill_implementation (no_tid=0, signo=6,
> threadid=140380599453504) at ./nptl/pthread_kill.c:44
> #1 __pthread_kill_internal (signo=6, threadid=140380599453504) at
> ./nptl/pthread_kill.c:78
> #2 __GI___pthread_kill (threadid=140380599453504, signo=signo(at)entry=6) at
> ./nptl/pthread_kill.c:89
> #3 0x00007face7209476 in __GI_raise (sig=sig(at)entry=6) at
> ../sysdeps/posix/raise.c:26
> #4 0x00007face71ef7f3 in __GI_abort () at ./stdlib/abort.c:79
> #5 0x0000558b58981037 in ExceptionalCondition
> (conditionName=conditionName(at)entry=0x558b589e6a80 "parent->lsn !=
> PageGetLSN(parent->page) || is_build",
> fileName=fileName(at)entry=0x558b58b44840 "gist.c",
> lineNumber=lineNumber(at)entry=1050)
> at assert.c:66
> #6 0x0000558b58452dc3 in gistFindCorrectParent (r=0x7facdb4a6760,
> child=child(at)entry=0x558b5978ac68, is_build=<optimized out>) at gist.c:1050
> #7 0x0000558b58455407 in gistfinishsplit (state=state(at)entry
> =0x7ffd28324ee0,
> stack=stack(at)entry=0x558b5978ac68, giststate=giststate(at)entry
> =0x558b59712ad8,
> splitinfo=<optimized out>, unlockbuf=unlockbuf(at)entry=true) at gist.c:1394
> #8 0x0000558b58455122 in gistinserttuples
> (state=state(at)entry=0x7ffd28324ee0, stack=0x558b5978ac68,
> giststate=giststate(at)entry=0x558b59712ad8,
> tuples=tuples(at)entry=0x7ffd28324c80, ntup=ntup(at)entry=2,
> oldoffnum=<optimized
> out>,
> leftchild=-37, rightchild=-40, unlockbuf=true, unlockleftchild=false)
> at
> gist.c:1324
> #9 0x0000558b58455437 in gistfinishsplit (state=state(at)entry
> =0x7ffd28324ee0,
> stack=stack(at)entry=0x558b59720148, giststate=giststate(at)entry
> =0x558b59712ad8,
> splitinfo=<optimized out>, unlockbuf=unlockbuf(at)entry=false) at gist.c:1395
> #10 0x0000558b58455122 in gistinserttuples
> (state=state(at)entry=0x7ffd28324ee0, stack=0x558b59720148,
> giststate=giststate(at)entry=0x558b59712ad8,
> tuples=tuples(at)entry=0x558b59760c60, ntup=ntup(at)entry=1,
> oldoffnum=oldoffnum(at)entry=0,
> leftchild=-33, rightchild=-34, unlockbuf=false, unlockleftchild=false)
> at gist.c:1324
> #11 0x0000558b584552ee in gistfinishsplit (state=state(at)entry
> =0x7ffd28324ee0,
> stack=stack(at)entry=0x558b59738178, giststate=giststate(at)entry
> =0x558b59712ad8,
> splitinfo=0x558b59760be8, unlockbuf=unlockbuf(at)entry=false) at gist.c:1370
> #12 0x0000558b58455122 in gistinserttuples
> (state=state(at)entry=0x7ffd28324ee0, stack=stack(at)entry=0x558b59738178,
> giststate=giststate(at)entry=0x558b59712ad8,
> tuples=tuples(at)entry=0x7ffd28324e78, ntup=ntup(at)entry=1,
> oldoffnum=oldoffnum(at)entry=0, leftchild=0, rightchild=0,
> unlockbuf=false,
> unlockleftchild=false) at gist.c:1324
> #13 0x0000558b5845584e in gistinserttuple (state=state(at)entry
> =0x7ffd28324ee0,
> stack=stack(at)entry=0x558b59738178, giststate=giststate(at)entry
> =0x558b59712ad8,
> tuple=<optimized out>, tuple(at)entry=0x558b5971b228,
> oldoffnum=oldoffnum(at)entry=0)
> at gist.c:1250
> #14 0x0000558b58455df0 in gistdoinsert (r=r(at)entry=0x7facdb4a6760,
> itup=0x558b5971b228, freespace=freespace(at)entry=0,
> giststate=giststate(at)entry=0x558b59712ad8,
> heapRel=heapRel(at)entry=0x7facdb4a0e48, is_build=is_build(at)entry=false)
> at gist.c:886
> #15 0x0000558b584568df in gistinsert (r=0x7facdb4a6760,
> values=0x7ffd283250a0, isnull=0x7ffd28325080, ht_ctid=0x558b596f5428,
> heapRel=0x7facdb4a0e48, checkUnique=<optimized out>, indexUnchanged=false,
> indexInfo=0x558b596f6938)
> at gist.c:184
> #16 0x0000558b5849b579 in index_insert
> (indexRelation=indexRelation(at)entry=0x7facdb4a6760,
> values=values(at)entry=0x7ffd283250a0, isnull=isnull(at)entry=0x7ffd28325080,
> heap_t_ctid=heap_t_ctid(at)entry=0x558b596f5428,
> heapRelation=heapRelation(at)entry=0x7facdb4a0e48,
> checkUnique=checkUnique(at)entry=UNIQUE_CHECK_NO, indexUnchanged=false,
> indexInfo=0x558b596f6938) at indexam.c:235
> #17 0x0000558b5864e668 in ExecInsertIndexTuples
> (resultRelInfo=resultRelInfo(at)entry=0x558b596de518,
> slot=slot(at)entry=0x558b596f53f8, estate=estate(at)entry=0x558b596ba2f8,
> update=update(at)entry=false, noDupErr=noDupErr(at)entry=false,
> specConflict=specConflict(at)entry=0x0, arbiterIndexes=0x0,
> onlySummarizing=false) at execIndexing.c:432
> #18 0x0000558b5868422f in ExecInsert (context=context(at)entry
> =0x7ffd28325300,
> resultRelInfo=resultRelInfo(at)entry=0x558b596de518, slot=0x558b596f53f8,
> canSetTag=true, inserted_tuple=inserted_tuple(at)entry=0x0,
> insert_destrel=insert_destrel(at)entry=0x0) at nodeModifyTable.c:1139
> ...
>
> Reproduced on REL_12_STABLE .. master, starting from the commit 28d3c2ddc,
> which introduced this assert.
>

Thanks for your report. I can reproduce this issue.
I try to delete the Assert, no coredump anymore.
I need some time to learn GiST to find the root cause.

--
Tender Wang
OpenPie: https://en.openpie.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2024-03-19 12:33:01 Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Previous Message Dave Cramer 2024-03-19 11:39:06 Re: Postgres jdbc driver inconsistent behaviour with double precession