Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows - Mailing list pgsql-bugs

From Alexander Korotkov
Subject Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Date
Msg-id CAPpHfdu=aJWWQQfgXZq-dSLmWQMr11KgsztEGFZNLiWMfSAUOA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Fri, Jun 18, 2021 at 1:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > On Thu, Jun 17, 2021 at 10:49 PM Tom Lane <tgl@sss.pgh.pa.us> 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.

Yes, that's it.  Thank you for correction.

> 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.

+1, sounds like a good idea.

------
Regards,
Alexander Korotkov



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Next
From: PG Bug reporting form
Date:
Subject: BUG #17063: repmgrd_upstream_reconnect getting more