Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns.
Tom Lane <tgl@sss.pgh.pa.us>
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-12T03:00:31Z
Lists: pgsql-bugs
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 →
-
Fix GIN's shimTriConsistentFn to not corrupt its input.
- e708ffe79df0 18.0 landed
- c7597a1d369c 13.21 landed
- 9a8c16aeccad 15.13 landed
- 8c153fcfa0d6 17.5 landed
- 4b65b085aff2 16.9 landed
- 1b47a112ac41 14.18 landed
-
Fix some performance issues in GIN query startup.
- 0f21db36d663 18.0 landed
- e2a6934a8855 14.18 landed
- d52221cf0de4 16.9 landed
- 9094eb25b7d9 17.5 landed
- 308d0d443770 13.21 landed
- 2d313375c092 15.13 landed