| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Missing CFI in hlCover()? |
| Date: | 2020-07-30 21:42:19 |
| Message-ID: | 1611391.1596145339@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>>> We could hard-code a rule like that, or we could introduce a new
>>>> explicit parameter for the maximum cover length. The latter would be
>>>> more flexible, but we need something back-patchable and I'm concerned
>>>> about the compatibility hazards of adding a new parameter in minor
>>>> releases. So on the whole I propose hard-wiring a multiplier of,
>>>> say, 10 for both these cases.
>>> That sounds alright to me, though I do think we should probably still
>>> toss a CFI (or two) in this path somewhere as we don't know how long
>>> some of these functions might take...
>> Yeah, of course. I'm still leaning to doing that in TS_execute_recurse.
> Works for me.
Here's a proposed patch along that line.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| fix-slow-ts_headline.patch | text/x-diff | 4.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2020-07-30 21:47:23 | Re: psql - improve test coverage from 41% to 88% |
| Previous Message | Daniel Gustafsson | 2020-07-30 21:42:16 | Re: OpenSSL randomness seeding |