Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lu07d-0003ng-Gc for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Jun 2021 22:04:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lu07c-0004ZV-5m for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Jun 2021 22:04:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lu07b-0004ZN-V4 for pgsql-bugs@lists.postgresql.org; Thu, 17 Jun 2021 22:04:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lu07Z-00086O-9X for pgsql-bugs@lists.postgresql.org; Thu, 17 Jun 2021 22:04:22 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 15HM48S51068522; Thu, 17 Jun 2021 18:04:08 -0400 From: Tom Lane To: Alexander Korotkov cc: Heikki Linnakangas , Pawel Kudzia , PostgreSQL mailing lists Subject: Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows In-reply-to: References: <16792-b1913b6b4e098331@postgresql.org> <970432.1623938874@sss.pgh.pa.us> <1039976.1623959387@sss.pgh.pa.us> Comments: In-reply-to Alexander Korotkov message dated "Fri, 18 Jun 2021 00:55:56 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1068520.1623967448.1@sss.pgh.pa.us> Date: Thu, 17 Jun 2021 18:04:08 -0400 Message-ID: <1068521.1623967448@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Korotkov writes: > On Thu, Jun 17, 2021 at 10:49 PM Tom Lane wrote: >> we need to add some code that checks for default searchMode, and in >> that case doesn't call the consistentFn unless at least one >> (non-MAYBE) input is TRUE. > I think in default search mode we can just start with curResult equal > to GIN_FALSE instead of calling directBoolConsistentFn(). No, it's not that simple, because there might be other keys that are TRUE not MAYBE. So the result could legitimately be TRUE in this case. BTW, I think it'd be a really good idea for this function to restore all the MAYBE entries to GIN_MAYBE before returning, so that you can remove the caveat that it destroys the contents of entryRes[]. I have basically zero faith that that's safe, and it seems pretty cheap to not have to make the assumption. regards, tom lane