Horton
Menu

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

Vinod Sridharan <vsridh90@gmail.com>

View thread
From: Vinod Sridharan <vsridh90@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: niek.brasa@hitachienergy.com, pgsql-bugs@lists.postgresql.org
Date: 2025-04-12T03:30:43Z
Lists: pgsql-bugs 
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@sss.pgh.pa.us> wrote:
>
> Vinod Sridharan <vsridh90@gmail.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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix GIN's shimTriConsistentFn to not corrupt its input.

  2. Fix some performance issues in GIN query startup.