Re: BUG #16865: Regression: GIN Negated prefix search returns results that contain the search term
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Nüscheler <dimitri.nuescheler@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, Pavel Borisov <pashkin.elfe@gmail.com>
Date: 2021-02-15T23:26:48Z
Lists: pgsql-bugs
Attachments
- fix-lossy-gin-index-behavior.patch (text/x-diff) patch
=?UTF-8?Q?Dimitri_N=C3=BCscheler?= <dimitri.nuescheler@gmail.com> writes: > Meanwhile I managed to anonymize the data. I put it in this archive > https://www.violetsky.ch/postgres-issue-anonymized.tar.gz Thanks. I've reproduced the issue and it boils down to doing the wrong thing when there are GIN_MAYBE values in the input data for checkcondition_gin, specifically when the bitmap holding the original GIN index results has become lossy. We correctly get a TS_MAYBE result out of the calculation in TS_execute_recurse, but then TS_execute figures it can throw that detail away and just return TS_YES. I think that this problem existed before 2f2007fbb, but we were masking it by always forcing rechecks. Anyway, this seems to put the final nail in the coffin of the idea that it's sufficient for TS_execute to return a boolean. At least the tsginidx.c callers really need to see the 3-way result. Hence I propose the attached patch. It fixes the given test case, but I wonder if you can try it and see if you see any remaining problems. I wasted quite a bit of time trying to devise a test case that is short enough to be reasonable to include in our regression tests, without success ... you need quite a bit of data to make the GIN bitmap become lossy. So no test case here, but I'm not super comfortable with that. regards, tom lane
Commits
-
Convert tsginidx.c's GIN indexing logic to fully ternary operation.
- 38bb3aef354c 14.0 landed
- 0d779d22a290 13.3 landed
-
Rename configure.in to configure.ac
- 25244b8972a3 14.0 cited