From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pawel Kudzia <kudzia@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16792: silent corruption of GIN index resulting in SELECTs
 returning non-matching rows
In-reply-to: 
 <CAJYBUS8p3aYh5ZWJHHk1QGnGkUepMHQMMm87kODoXOFS+VWVGQ@mail.gmail.com>
References: <16792-b1913b6b4e098331@postgresql.org>
 <CAJYBUS9AaEgFTXnZnAWir993-MOVLnXefQmyLd9erXewZhXiHA@mail.gmail.com>
 <CAJYBUS_5Z+9aHyNQ7wkTEkZF+c_RMn7hMjPkTGU0Uc7OHMU3sQ@mail.gmail.com>
 <CAJYBUS8p3aYh5ZWJHHk1QGnGkUepMHQMMm87kODoXOFS+VWVGQ@mail.gmail.com>
Comments: In-reply-to Pawel Kudzia <kudzia@gmail.com>
	message dated "Thu, 17 Jun 2021 10:00:10 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <970431.1623938874.1@sss.pgh.pa.us>
Date: Thu, 17 Jun 2021 10:07:54 -0400
Message-ID: <970432.1623938874@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/970432.1623938874%40sss.pgh.pa.us>
Precedence: bulk

Pawel Kudzia <kudzia@gmail.com> writes:
> with help from IRC we've found that decreasing work_mem from 1MB to 256kB
> or less makes the problem go away:

Hmm.  So that suggests that the index itself is *not* corrupt,
but the problem is associated with a bug in the indexscan
algorithms.

Have you experimented with different index opclasses?  Your
original report said you were using gin__int_ops, but that's
not the default, and we sort of deprecate intarray these days.

			regards, tom lane