On Sat, 22 Feb 2025 at 03:51, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
> > On Feb 21, 2025, at 12:50 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> >
> > Could one of the patch authors take a look?
>
> I turned the TAP test which triggers the error into a regression test that does likewise, for ease of stepping
throughthe test, if anybody should want to do that. I'm attaching that patch here, but please note that I'm not
expectingthis to be committed.
Hi!
Your efforts are much appreciated!
I used this patch to derive a smaller repro.
> this seems to either be a bug in the checking code complaining about perfectly valid tuple order,
I'm doubtful this is the case. I have added some more logging to
gin_index_check, and here is output after running attached:
```
DEBUG: processing entry tree page at blk 2, maxoff: 125
....
DEBUG: comparing for offset 78 category 0
DEBUG: comparing for offset 79 category 2
DEBUG: comparing for offset 80 category 3
DEBUG: comparing for offset 81 category 0
LOG: index "ginidx" has wrong tuple order on entry tree page, block
2, offset 81, rightlink 4294967295
DEBUG: comparing for offset 82 category 0
....
DEBUG: comparing for offset 100 category 0
DEBUG: comparing for offset 101 category 2
DEBUG: comparing for offset 102 category 3
DEBUG: comparing for offset 103 category 0
LOG: index "ginidx" has wrong tuple order on entry tree page, block
2, offset 103, rightlink 4294967295
DEBUG: comparing for offset 104 category 0
DEBUG: comparing for offset 105 category 0
```
So, we have an entry tree page, where there is tuple on offset 80,
with gin tuple category = 3, and then it goes category 0 again. And
one more such pattern on the same page.
The ginCompareEntries function compares the gin tuples category first.
I do not understand how this would be a valid order on the page, given
that
ginCompareEntries used in `ginget.c` logic. . Maybe I'm missing
something vital about GIN.
--
Best regards,
Kirill Reshke
