Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0 - Mailing list pgsql-bugs

From Palak Chaturvedi
Subject Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
Date
Msg-id CALfch1_qFgqr24XQY4kB93Gr62Jx+GUqLA0QYTpWsfrEZZ0wWg@mail.gmail.com
Whole thread
In response to Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0  (Manu <manuelreyesbravo@gmail.com>)
Responses Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
List pgsql-bugs
Hi Manu,

Thanks for v2. Both suggestions are covered. All four pg_trgm
regression tests pass on an assertion-enabled master build, and
the new cases fail without the fix.

No further comments from me. The patch look good to me.

Regards,
Palak

On Fri, 25 Sept 2026 at 21:08, Manu <manuelreyesbravo@gmail.com> wrote:
>
> Hi Palak,
>
> Thanks for the review and for the row-set comparison.
>
> On Fri, 25 Sept 2026, Palak Chaturvedi wrote:
> > * Insert rows after creating the GIN index, then test an empty
> >   query at threshold zero before and after pending-list cleanup.
> >
> > * Include strict-word similarity (<<%) at zero, with stored empty
> >   strings and NULLs.
>
> Both are in v2, attached.  The new test uses a small table holding
> two words, two empty strings and a NULL, inserted after the GIN index
> is created.  It runs % and <<%, with an empty and a non-empty query,
> before and after gin_clean_pending_list().  It then rebuilds the index
> as GiST and repeats the <<% queries.  I added 1000 rows before the
> GiST build: with only five rows the index is a single leaf page, and
> leaf pages were already correct.
>
> Without the C changes, each of the eight GIN queries returns 0 or 1
> row instead of 4, both before and after the cleanup, and the empty
> <<% query on GiST returns 0 instead of 1004.  With them, pg_trgm's
> tests pass.  I checked this on master (45da2c1d756) and on
> REL_14_STABLE, where v2 also applies cleanly.
>
> Regards,
> Manu



pgsql-bugs by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation
Next
From: Manu
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE + INSERT leads to index corruption