From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vinod Sridharan <vsridh90(at)gmail(dot)com> |
Cc: | niek(dot)brasa(at)hitachienergy(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |
Date: | 2025-04-11 23:54:40 |
Message-ID: | 1026035.1744415680@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Vinod Sridharan <vsridh90(at)gmail(dot)com> writes:
> I believe there may be an issue with the above patch - specifically in
> the case of the triConsistent logic dealing with op-classes that use
> the consistent function. In the shimTriConsistentFn, the key's
> entryRes values are directly mutated to set to GIN_FALSE (if there's
> fewer than MAX_MAYBE_ENTRIES entries). At the end of this method,
> they're not reset back to GIN_MAYBE. Consequently, the next loop of
> the ginFillScanEntry now may incorrectly assume that the remaining
> entries are GIN_FALSE when they started as GIN_MAYBE: previously they
> were hard reset for every iteration of the ginFillScanEntry loop. The
> attached patch seems to fix it by resetting any mutated values back
> before returning. However, this would also reset it during the regular
> triConsistent check per tuple.
This patch would be more convincing with a test case demonstrating
that there's a problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vinod Sridharan | 2025-04-12 02:17:28 | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |
Previous Message | Vinod Sridharan | 2025-04-11 23:38:29 | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |