| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vinod Sridharan <vsridh90(at)gmail(dot)com> |
| Cc: | niek(dot)brasa(at)hitachienergy(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |
| Date: | 2025-04-12 05:33:07 |
| Message-ID: | 1126691.1744435987@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Vinod Sridharan <vsridh90(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vinod Sridharan | 2025-04-12 05:58:52 | Re: BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns. |
| Previous Message | PG Bug reporting form | 2025-04-12 03:34:59 | BUG #18893: Segfault during analyze pg_database |