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
PG Bug reporting form <noreply@postgresql.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
