pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Justin Pryzby <pryzby@telsasoft.com>
To: Andreas Seltenreich <andreas.seltenreich@credativ.de>
Cc: pgsql-hackers@postgresql.org, Jaime Casanova <jcasanov@systemguards.com.ec>
Subject: Re: [sqlsmith] Failed assertion in brin_minmax_multi_distance_float4 on REL_14_STABLE
Date: Fri, 5 Nov 2021 02:09:59 +0100
Message-ID: <668dc67a-9baf-e4ab-88b0-2c39c6a2f08e@enterprisedb.com> (raw)
In-Reply-To: <83b2e911-ccd9-5503-fb32-369050a6e93d@enterprisedb.com>
References: <87r1bw9ukm.fsf@credativ.de>
	<20211104165357.GU17618@telsasoft.com>
	<83b2e911-ccd9-5503-fb32-369050a6e93d@enterprisedb.com>



On 11/4/21 23:56, Tomas Vondra wrote:
> Hi,
> 
> On 11/4/21 17:53, Justin Pryzby wrote:
>> On Thu, Nov 04, 2021 at 09:46:49AM +0100, Andreas Seltenreich wrote:
>>> sqlsmith triggers the following assertion when testing REL_14_STABLE:
>>>
>>>      TRAP: FailedAssertion("a1 <= a2", File: "brin_minmax_multi.c", 
>>> Line: 1879, PID: 631814)
>>>
>>> I can reproduce it with the following query on a fresh regression
>>> database:
>>>
>>>      insert into public.brintest_multi (float4col) values (real 'nan');
>>>
>>> The branch was at f6162c020c while testing, backtrace below.
>>
>> I couldn't reproduce this, but it reminds me of this one, which we 
>> also had
>> trouble reproducing.
>>
> 
> I can reproduce that just fine - all I had to do was 'make installcheck' 
> and then connect to the regression db and run the insert.
> 
> It seems to be a simple case of confusion in handling of NaN values. We 
> do sort them correctly (by calling float4_lt), but given two values
> 
>    arg1 = nan (0x400000)
>    arg2 = 0.0909090936
> 
> then a simple comparison does not give the expected result
> 
>    (arg1 < arg2)
>    (arg1 == arg2)
>    (arg1 > arg2)
> 
> all evaluate to false, which is why the assert fails. So I guess the 
> distance function for float4 (and probably float8 too) need a couple 
> more lines checking NaN.
> 

Here's a patch that should fix this. It simply handled NaN and returns 
distance 0.0 for two NaN values and Infinity for NaN vs. something else. 
I did check what happens with Infinity values, but I think those are 
fine - we can actually calculate distance with them, and the assert 
works for them too.

I'll improve the regression tests to include a couple NaN/Infinity cases 
tomorrow, and then I'll get this pushed.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company





view thread (5+ messages)  latest in thread

Message-ID: <668dc67a-9baf-e4ab-88b0-2c39c6a2f08e@enterprisedb.com>
Permalink:  ../668dc67a-9baf-e4ab-88b0-2c39c6a2f08e@enterprisedb.com/
Also on:    postgresql.org/message-id/668dc67a-9baf-e4ab-88b0-2c39c6a2f08e@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@enterprisedb.com, pryzby@telsasoft.com, andreas.seltenreich@credativ.de, jcasanov@systemguards.com.ec
  Subject: Re: [sqlsmith] Failed assertion in brin_minmax_multi_distance_float4 on REL_14_STABLE
  In-Reply-To: <668dc67a-9baf-e4ab-88b0-2c39c6a2f08e@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox