> On Fri, Jun 25, 2021 at 11:48 PM Alexander Korotkov
> <aekorotkov@gmail.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?
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)".
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?
--
regards,
Pawel Kudzia