Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns.
От | Vinod Sridharan |
---|---|
Тема | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |
Дата | |
Msg-id | CAFMdLD4Ks5b=CbBh1PjFSytm0zdNv9-ddyeE+opusAKCVph7=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns.
|
Список | 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
В списке pgsql-bugs по дате отправления: