From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Dolgov <9erthalion6@gmail.com>
cc: John Naylor <john.naylor@enterprisedb.com>, tharakan@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17774: Assert triggered on brin_minmax_multi.c
In-reply-to: <20230208100658.mz2kkeruoma6iqtw@ddolgov.remote.csb>
References: <17774-c6f3e36dd4471e67@postgresql.org>
 <CAFBsxsEMigeTVhBOpsBHw+SJS1n776akNqVC8ATEDmGo_OPgrw@mail.gmail.com>
 <20230208100658.mz2kkeruoma6iqtw@ddolgov.remote.csb>
Comments: In-reply-to Dmitry Dolgov <9erthalion6@gmail.com>
	message dated "Wed, 08 Feb 2023 11:06:58 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3485883.1675868581.1@sss.pgh.pa.us>
Date: Wed, 08 Feb 2023 10:03:01 -0500
Message-ID: <3485884.1675868581@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3485884.1675868581%40sss.pgh.pa.us>
Precedence: bulk

Dmitry Dolgov <9erthalion6@gmail.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.

			regards, tom lane