Re: BUG #16595: Reads fail with "lost saved point in index" error after writes

Thanks for the quick reply!

It sounds like this isn't a known problem, and that the only workaround
might be just dropping the index. Hmm!

So far, we've had fine luck simply retrying on error, and retries typically
succeed, so that's also a fine path forward.

Thanks again!

- jesse

On Thu, Aug 27, 2020 at 8:01 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > The table in question has a JSONB column with a GIN index, defined as:
> > "index_name_idx" gin (jsonb_column_name jsonb_path_ops, integer_column,
> > timestamp_with_time_zone_column)
> > Under load (especially writes followed immediately by reads), we
> > occasionally see reads failing an internal exception (error code XX000)
> with
> > the message "lost saved point in index".
>
> [ stares at that for awhile... ] Hm, I think this is just broken for
> multi-column GIN indexes. The code is expecting that it can re-find
> an index item that was there before, and that the item must either be
> where it was before in the index or somewhere to the right. Both
> of those assumptions seem valid, since ginvacuum never removes items;
> but insertions could push the item to the right.
>
> But this:
>
> if (gintuple_get_attrnum(btree->ginstate, itup) != attnum)
> elog(ERROR, "lost saved point in index"); /* must
> not happen !!! */
>
> amounts to an assumption that things can't get pushed so far to the
> right that our pointer is now pointing at an item with lower attnum.
> There's no reason for that to be true --- AFAICS, the attnum is the
> first sort key for the items, but there's not physical segregation
> into different index pages or anything like that.
>
> We could throw an error if we reach a higher attnum, but since the
> whole thing is supposed to be can't-happen, I doubt it's worth
> expending code on. What we should do is just advance over any
> item that hasn't got the right attnum.
>
> regards, tom lane
>