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-11T23:54:40Z
Lists: pgsql-bugs 
Vinod Sridharan <vsridh90@gmail.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

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.