| From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, tharakan(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17774: Assert triggered on brin_minmax_multi.c |
| Date: | 2023-02-08 15:33:13 |
| Message-ID: | 20230208153313.fym7at3ubgrec67a@ddolgov.remote.csb |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On Wed, Feb 08, 2023 at 10:03:01AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> > The negative delta might be only a consequence. From what I see it's
> > called from build_distances, and the idea is to find the gaps between
> > the max value of the current interval and the min value of the next one,
> > so they should be ordered and delta should be always positive.
>
> I'd believe this argument more readily if the calculation weren't being
> done in float arithmetic. Since it is, you're at the mercy of roundoff
> error ... and that small negative delta could certainly pass for
> roundoff error.
>
> Clamping the result to [0,1] would be a brighter plan than just asserting
> that it's in-range.
Hmm...yeah, good point. In both the reproducer I've posted and the
backtrace from the thread the delta is indeed rather small.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmytro Hanzhelo | 2023-02-08 15:42:37 | Re: BUG #17782: ERROR: variable not found in subplan target lists |
| Previous Message | Tom Lane | 2023-02-08 15:03:01 | Re: BUG #17774: Assert triggered on brin_minmax_multi.c |