Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns.

Hey Tom,
I concur with your statement - from a correctness standpoint this
should be what we do.
Since this is also called in the regular consistent function, this
would be adding work in the regular consistent path - where the caller
happens to reset the array for every invocation currently.

If we're okay with that, I would prefer to have this contract clean
too - which would also make it better if the consistent path were to
change in the future.

And yeah in that case, I believe my patch is sufficient.

-Vinod

On Fri, 11 Apr 2025 at 20:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Vinod Sridharan <vsridh90(at)gmail(dot)com> writes:
> > -- create textops operator class without triconsistent
>
> OK, got it, and I concur that we need to make shimTriConsistentFn()
> restore the state of the entryRes array before it returns. But
> I don't understand why you're concerned about "However, this would
> also reset it during the regular triConsistent check per tuple"?
> I think the point is basically that this function is violating
> the expectation that triconsistent functions not change the state
> of that array. That expectation doesn't depend on what the call
> site is.
>
> regards, tom lane