On 05/07/2021 16:36, Pawel Kudzia wrote:
> i have a consistent file-level backup of postgresql's /var/lib/postgresql +
> /etc/postgresql on which i can reproduce the issue reliably. it's on a test
> machine where we can put patched version of PG. currently this machine
> is using Debian 13.3-1.pgdg100+1.
>
> set enable_seqscan=off;
> SELECT entity_id FROM entity WHERE ( attribute_name_ids && '{1737}' )
> AND NOT ( (attribute_name_ids||0) && '{1737}') LIMIT 10;
>
> returns me 2 rows while it should return none.
>
> also in this case lowering work_mem from 1MB to 256kB makes fixes the
> issue - SELECT returns 0 rows instead of 2.
>
> i'll be happy to run patched version and send you back logs produced by it.
Thanks! Here's a patch that prints lines with "GINBUG:" prefix in the
log. It should apply cleanly to PostgreSQL v13.
This should help to confirm whether the bugs in shimTriConsistentFn that
Tom pointed out are the root cause of this issue. It should also tell us
whether the rows are being returned from the pending-inserts list or the
regular part of the GIN index.
We might need a few iterations to test different theories, but we'll get
there...
- Heikki
Ps. Sorry for the delay, I didn't see you reply until now, it went into
spam folder