Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows

>
>
> On Thu, Jul 15, 2021 at 4:27 PM Pawel Kudzia <kudzia(at)gmail(dot)com> wrote:
> > > On Fri, Jun 25, 2021 at 11:48 PM Alexander Korotkov
> > > <aekorotkov(at)gmail(dot)com> wrote:
> > > > Do you think it also worth checking whether bug persists when set
> > > > fastupdate = off. Then we could localize whether bug is related to
> > > > pending lists.
> > >
> > > I still think this is worth checking. Despite the pending list wasn't
> > > involved in the index scan with wrong results, the bug could be
> > > related to insertion to the pending list. Or it could be related to
> > > moving entries from the pending list to the posting list/tree.
> > >
> >
> > regarding fastupdate - i'd like to clarify. do i understand correctly
> > that this parameter affects what happens when rows are
> > inserted/updated/deleted?
>
> Yes, that's it.
>
> > if yes - we no longer have such workload on the production and we
> > cannot anymore and i was never able to find reproducible scenario.
> > the production environment was moved away from index built "USING gin
> > (attribute_name_ids public.gin__int_ops)" to index "USING gin
> > (attribute_name_ids)".
>
> Do I understand correctly that after the production environment moved
> away from the usage of contrib/intarray opclass to builtin opclass,
> the error has gone?
>

it's a bit too early to be confident - i'd give it at least 2-3 more weeks
before stating that the problem was solved.

in the past, when using gin__int_ops, we had periods of few consecutive
days when we did not catch any inconsistent reposnes.

> > the only thing i have right two file-level backups of postgresql data
> > directory on which i know that SELECTs return rows that actually don't
> > meet provided criteria.
> >
> > is there any point in testing fastupdate = off on those two snapshots?
>
> OK, I see. No point in trying fastupdate = off unless we can try to
> reproduce the index corruption.
>

thx for the clarification!

i'm happy to help with running more diagnostics on the database dumps that
i've saved, where very specific SELECTs return rows that don't match
provided criteria.

greetings!

--
regards,
Pawel Kudzia