Re: BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index - Mailing list pgsql-bugs
From | Tender Wang |
---|---|
Subject | Re: BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index |
Date | |
Msg-id | CAHewXN=FDqixMYCJXbdmH=P7GPBE_zH0HzQYkdSCxOtP6=VYiw@mail.gmail.com Whole thread Raw |
In response to | BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index (PG Bug reporting form <noreply@postgresql.org>) |
Responses |
Re: BUG #18396: Assert in gistFindCorrectParent() fails on inserting large tuples into gist index
|
List | pgsql-bugs |
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/pgsql-bugs by date: