From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16134: Assertion fails on CREATE gist INDEX over intarray
Date: Sun, 24 Nov 2019 12:38:50 -0500
Message-ID: <9409.1574617130@sss.pgh.pa.us> (raw)
In-Reply-To: <16134-0423f729671dec64@postgresql.org>
References: <16134-0423f729671dec64@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16134: Assertion fails on CREATE gist INDEX over intarray
In-Reply-To: <9409.1574617130@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox