Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0

From: Palak Chaturvedi <chaturvedipalak1911(at)gmail(dot)com>
To: Manu <manuelreyesbravo(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, kehan5800(at)gmail(dot)com
Subject: Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
Date: 2026-09-27 15:08:08
Message-ID: CALfch1_qFgqr24XQY4kB93Gr62Jx+GUqLA0QYTpWsfrEZZ0wWg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Manu 2026-09-27 16:11:13 Re: BUG #19686: Rolling back SET TABLESPACE + INSERT leads to index corruption
Previous Message Kirill Reshke 2026-09-27 10:33:39 Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation