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

PG Bug reporting form <noreply@postgresql.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@gmail.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@entry=6) at
> ./nptl/pthread_kill.c:89
> #3  0x00007face7209476 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> #4  0x00007face71ef7f3 in __GI_abort () at ./stdlib/abort.c:79
> #5  0x0000558b58981037 in ExceptionalCondition
> (conditionName=conditionName@entry=0x558b589e6a80 "parent->lsn !=
> PageGetLSN(parent->page) || is_build",
> fileName=fileName@entry=0x558b58b44840 "gist.c",
> lineNumber=lineNumber@entry=1050)
>     at assert.c:66
> #6  0x0000558b58452dc3 in gistFindCorrectParent (r=0x7facdb4a6760,
> child=child@entry=0x558b5978ac68, is_build=<optimized out>) at gist.c:1050
> #7  0x0000558b58455407 in gistfinishsplit (state=state@entry
> =0x7ffd28324ee0,
> stack=stack@entry=0x558b5978ac68, giststate=giststate@entry
> =0x558b59712ad8,
> splitinfo=<optimized out>, unlockbuf=unlockbuf@entry=true) at gist.c:1394
> #8  0x0000558b58455122 in gistinserttuples
> (state=state@entry=0x7ffd28324ee0, stack=0x558b5978ac68,
> giststate=giststate@entry=0x558b59712ad8,
> tuples=tuples@entry=0x7ffd28324c80, ntup=ntup@entry=2,
> oldoffnum=<optimized
> out>,
>     leftchild=-37, rightchild=-40, unlockbuf=true, unlockleftchild=false)
> at
> gist.c:1324
> #9  0x0000558b58455437 in gistfinishsplit (state=state@entry
> =0x7ffd28324ee0,
> stack=stack@entry=0x558b59720148, giststate=giststate@entry
> =0x558b59712ad8,
> splitinfo=<optimized out>, unlockbuf=unlockbuf@entry=false) at gist.c:1395
> #10 0x0000558b58455122 in gistinserttuples
> (state=state@entry=0x7ffd28324ee0, stack=0x558b59720148,
> giststate=giststate@entry=0x558b59712ad8,
> tuples=tuples@entry=0x558b59760c60, ntup=ntup@entry=1,
> oldoffnum=oldoffnum@entry=0,
>     leftchild=-33, rightchild=-34, unlockbuf=false, unlockleftchild=false)
> at gist.c:1324
> #11 0x0000558b584552ee in gistfinishsplit (state=state@entry
> =0x7ffd28324ee0,
> stack=stack@entry=0x558b59738178, giststate=giststate@entry
> =0x558b59712ad8,
> splitinfo=0x558b59760be8, unlockbuf=unlockbuf@entry=false) at gist.c:1370
> #12 0x0000558b58455122 in gistinserttuples
> (state=state@entry=0x7ffd28324ee0, stack=stack@entry=0x558b59738178,
> giststate=giststate@entry=0x558b59712ad8,
> tuples=tuples@entry=0x7ffd28324e78, ntup=ntup@entry=1,
>     oldoffnum=oldoffnum@entry=0, leftchild=0, rightchild=0,
> unlockbuf=false,
> unlockleftchild=false) at gist.c:1324
> #13 0x0000558b5845584e in gistinserttuple (state=state@entry
> =0x7ffd28324ee0,
> stack=stack@entry=0x558b59738178, giststate=giststate@entry
> =0x558b59712ad8,
> tuple=<optimized out>, tuple@entry=0x558b5971b228,
> oldoffnum=oldoffnum@entry=0)
>     at gist.c:1250
> #14 0x0000558b58455df0 in gistdoinsert (r=r@entry=0x7facdb4a6760,
> itup=0x558b5971b228, freespace=freespace@entry=0,
> giststate=giststate@entry=0x558b59712ad8,
> heapRel=heapRel@entry=0x7facdb4a0e48, is_build=is_build@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@entry=0x7facdb4a6760,
> values=values@entry=0x7ffd283250a0, isnull=isnull@entry=0x7ffd28325080,
> heap_t_ctid=heap_t_ctid@entry=0x558b596f5428,
>     heapRelation=heapRelation@entry=0x7facdb4a0e48,
> checkUnique=checkUnique@entry=UNIQUE_CHECK_NO, indexUnchanged=false,
> indexInfo=0x558b596f6938) at indexam.c:235
> #17 0x0000558b5864e668 in ExecInsertIndexTuples
> (resultRelInfo=resultRelInfo@entry=0x558b596de518,
> slot=slot@entry=0x558b596f53f8, estate=estate@entry=0x558b596ba2f8,
> update=update@entry=false, noDupErr=noDupErr@entry=false,
>     specConflict=specConflict@entry=0x0, arbiterIndexes=0x0,
> onlySummarizing=false) at execIndexing.c:432
> #18 0x0000558b5868422f in ExecInsert (context=context@entry
> =0x7ffd28325300,
> resultRelInfo=resultRelInfo@entry=0x558b596de518, slot=0x558b596f53f8,
> canSetTag=true, inserted_tuple=inserted_tuple@entry=0x0,
>     insert_destrel=insert_destrel@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/