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