Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
| От | Pawel Kudzia |
|---|---|
| Тема | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
| Дата | |
| Msg-id | CAJYBUS8s-yvokpZ7MLyfa3Ub2JxDb7kTYdih=ZvRNCgYMVUtyw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows (Alexander Korotkov <aekorotkov@gmail.com>) |
| Ответы |
Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
|
| Список | pgsql-bugs |
> 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
В списке pgsql-bugs по дате отправления: