Re: BUG #16134: Assertion fails on CREATE gist INDEX over intarray
От | Tom Lane |
---|---|
Тема | Re: BUG #16134: Assertion fails on CREATE gist INDEX over intarray |
Дата | |
Msg-id | 9409.1574617130@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16134: Assertion fails on CREATE gist INDEX over intarray (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > When running the following script (repeated to improve reproducing): > ... > Server (compiled with cassert) crashes: Yup, reproduced here. What I see is that gistnospace is being told to account for a "to-be-deleted" tuple that is off the end of the page's line pointer array. Tracing back to see where that tuple number is coming from, it seems to originate in gistfinishsplit: gistinserttuples(state, stack->parent, giststate, tuples, 2, stack->downlinkoffnum, left->buf, right->buf, true, /* Unlock parent */ unlockbuf /* Unlock stack->buffer if caller wants that */ ); That is, the stack->downlinkoffnum tuple index doesn't jibe with the actual state of the stack->parent page. What I suspect has happened is that the stack->parent page itself got split during some recursive split, and the stacked info wasn't updated. I don't know this code well enough to be sure though, and I definitely don't wish to be the one to fix it. regards, tom lane
В списке pgsql-bugs по дате отправления: