From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | exclusion(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16134: Assertion fails on CREATE gist INDEX over intarray |
Date: | 2019-11-24 17:38:50 |
Message-ID: | 9409.1574617130@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-11-24 23:40:11 | Re: Failed assertion clauses != NIL |
Previous Message | Petr Fedorov | 2019-11-24 14:10:33 | Precision/scale of a numeric attribute of a new data type are not handled correctly when the type is returned by a function |