On Thu, Jun 24, 2021 at 3:32 PM Pawel Kudzia <kudzia@gmail.com> wrote:
> > Pawel, is this a production system, or would it be possible for you to
> > build from sources with a patch with some extra debugging output?
> thank you for looking into it!
>
> it is a production system but we have couple of replicas. when the
> problem occurs - it can be reproduced on any replica as well. when
> it happens again - i can stop one of replicas, take file level backup
> and set up a test machine on which i can try to build PG from source,
> including your patch adding extra verbosity.
>
> please note that the last inconsistency was fixed, but i expect that
> new one will show up within few days.
hello again,
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.
greetings!
--
regards,
Pawel Kudzia
