Horton
Menu

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

Tom Lane <tgl@sss.pgh.pa.us>

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

Ah, so you're just worried about the extra work in that path?
But MAX_MAYBE_ENTRIES is only 4, so I can't believe it'd amount
to much.

I am wondering about a test case.  I'm not thrilled about building
a specialized opclass just to test this.  contrib/hstore and
contrib/intarray already have opclasses with no triconsistent
function, so they should (and do) exercise shimTriConsistentFn
already.  But their tests failed to expose this bug.  I spent
a bit of time trying to add an example that would show the bug
in one or the other of those, and failed so far.  Any ideas?

			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.