On Fri, 28 Feb 2025 at 23:31, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> The only obvious definition of "wrong" for this is that gin index scans return different result sets than table scans
overthe same data. Using your much smaller reproducible test case, and adding rows like:
Yeach, you are 100% right. Actually, along this thread, we have not
spotted any GIN bugs yet, only GIN amcheck bugs.
This turns out to be also an GIN amcheck bug:
```
DEBUG: comparing for offset 79 category 2 key attnum 1
DEBUG: comparing for offset 80 category 3 key attnum 1
DEBUG: comparing for offset 81 category 0 key attnum 2
LOG: index "ginidx" has wrong tuple order on entry tree page, block
2, offset 81, rightlink 4294967295
DEBUG: comparing for offset 82 category 0 key attnum 2
....
DEBUG: comparing for offset 100 category 0 key attnum 2
DEBUG: comparing for offset 101 category 2 key attnum 2
DEBUG: comparing for offset 102 category 3 key attnum 2
DEBUG: comparing for offset 103 category 0 key attnum 3
LOG: index "ginidx" has wrong tuple order on entry tree page, block
2, offset 103, rightlink 4294967295
DEBUG: comparing for offset 104 category 0 key attnum 3
DEBUG: comparing for offset 105 category 0 key attnum 3
```
Turns out we compare page entries for different attributes in
gin_check_parent_keys_consistency.
Trivial fix attached (see v37-0004). I now simply compare current and
prev attribute numbers. This revolves issue discovered by
`v0-0001-Add-a-reproducible-test-case-for-verify_gin-error.patch.no_apply`.
However, the stress test seems to still not pass. On my pc, it never
ens, all processes are in
DELETE waiting/UPDATE waiting state. I will take another look tomorrow.
p.s. I am just about to send this message, while i discovered we now
miss v34-0003-Add-gist_index_check-function-to-verify-GiST-ind.patch &
v34-0005-Add-GiST-support-to-pg_amcheck.patch from this patch series
;(
--
Best regards,
Kirill Reshke
