Re: BUG #19031: pg_trgm infinite loop on certain cases

Hi,

On Tue, Aug 26, 2025 at 3:54 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> ...
> However, I don't totally understand *why* it fixes the test case.
> Especially not after I noted that there's already a test case in
> pg_trgm that exercises exactly this situation:
>
> select count(*) from test_trgm where t like '%99%' and t like '%qwerty%';
>
> If you put an Assert into ginNewScanKey that the first scan key
> isn't excludeOnly (instead of the re-sort), it fails on that query.
> So why do we not see an infinite loop for that test case?  I don't
> really understand the GIN code well enough to figure out what is
> the difference.
>

I debug a little bit and it looks like the reason there's no infinite
loop in your example is because it returns MAYBE for the first
'excludeOnly' key in:

    keyGetItem()
        ...
        res = key->triConsistentFn(key);

so we set key->curItemMatches = true for the first key and move on to
the second normal key, allowing the scan to proceed and eventually
finish. In the bug repro, the first 'excludeOnly' key returns FALSE in
triConsistentFn, so we get stuck on the 'excludeOnly' key which never
finishes. I don't have an opinion on whether it's good or not to move
all the 'excludeOnly' keys to the end, but it seems that simply not
having an "excludeOnly" key as the first key is enough to fix the bug.
Maybe it's enough to just swap any normal key with the first one, if
it's "excludeOnly"?

> In the meantime, the 0001 patch attached moves the
> CHECK_FOR_INTERRUPTS() call in gingetbitmap to be inside the loop in
> scanGetItem, so that it's able to respond to a query cancel request in
> this situation.  I think we'd better do that even after fixing the
> present bug.

+1


Best regards,
Arseniy Mukhin