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 | CAJYBUS87K+=vp4Jaet1e4Fp2GVDHKznsm5wDSdXy+jMkmsMbyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
Список | pgsql-bugs |
On Fri, Jul 23, 2021 at 3:46 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > On 22/07/2021 12:07, Pawel Kudzia wrote: > > On Thu, Jul 22, 2021 at 9:25 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > >> > >> Fixed those bugs, new patch version attached. Pawel, can you test this > >> again, please? At this point, I'm pretty sure this isn't going to reveal > >> any more information about the original problem, but at least we're > >> ironing out bugs from the 'amcheck' patch.. > > > > thank you for the next patch Heikki! > > no crash this time! i'm sending a message in a separate mail since i'm > > not sure if it'll pass through attachment size limit that's applied > > for the list. > > Thanks! So looking at the log, amcheck is not reporting any more problems. > > >> I'm grasping at straws here, but here's one more thing we could try: the > >> query returned these incorrect tuples: > >> > >> ctid | entity_id > >> --------------+----------- > >> (4002784,1) | 38048120 > >> (4002869,14) | 95333744 > >> (2 rows) > >> > >> We know those entries are in the GIN index with key '1373', when they > >> shouldn't be. But I wonder if the correct keys for those tuples are > >> present? Pawel, can you try this, please: > > > > [queries with nore rows returned] > > Ok, so the index is missing entries for the correct key. Looks like the > index entries were inserted into the wrong subtree, under wrong key. But > *how* did that happen? I'm out of ideas, I'm afraid :-(. Thanks a lot for your patience and multiple patches that you've provided. Please pardon my ignorance - I don't have low-level understanding of how the query is being executed - but are you sure that index is missing entries and not the other way around - that it has too many entries? To recap - SELECT, answered based on the GIN, reports rows that actually do not match the criteria provided in WHERE. Just lowering work_mem makes the problem go away, whith GIN still being used. Greetings! -- regards, Pawel Kudzia
В списке pgsql-bugs по дате отправления: