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
In-reply-to: <16134-0423f729671dec64@postgresql.org>
References: <16134-0423f729671dec64@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 24 Nov 2019 07:33:34 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9408.1574617130.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 24 Nov 2019 12:38:50 -0500
Message-ID: <9409.1574617130@sss.pgh.pa.us>
Precedence: bulk

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