Thread: Windows env returns error while running "select pgstatindex"
Description:
===========
Error Message " invalid input syntax for type double precision: -1#I" is displayed while running "select pgstatindex"
Issue only getting reproduce on windows environment.
Analysis:
=========
Consider the following testcase to reproduce the issue on windows:
create table test (a int primary key );
Windows Output:
==============
psql>select pgstatindex('public.test_pkey');
Thanks,
Rushabh Lathia
===========
Error Message " invalid input syntax for type double precision: -1#I" is displayed while running "select pgstatindex"
Issue only getting reproduce on windows environment.
Analysis:
=========
Consider the following testcase to reproduce the issue on windows:
create table test (a int primary key );
Windows Output:
==============
psql>select pgstatindex('public.test_pkey');
ERROR: invalid input syntax for type double precision: "-1.#J"
Linux output:
==========
psql=# select pgstatindex('public.test_pkey');
pgstatindex
---------------------------
(2,0,0,0,0,0,0,0,NaN,NaN)
(1 row)
here when we run the select on linux its returning proper result and on windows error coming from float8in() while trying to work for the NaN values.
After debugging I noticed that "0/0" returning NaN on linux but it returns "-1.#JIND0000" on windows. Now when float8in() getting call for such value on windows it ending up with error "invalid input syntax for type double precision:" as strtod() not able to understand such values.
I added to check into pgstatindex() to avoid "0/0" situation and issue got fixed.
PFA patch for the same.
Linux output:
==========
psql=# select pgstatindex('public.test_pkey');
pgstatindex
---------------------------
(2,0,0,0,0,0,0,0,NaN,NaN)
(1 row)
here when we run the select on linux its returning proper result and on windows error coming from float8in() while trying to work for the NaN values.
After debugging I noticed that "0/0" returning NaN on linux but it returns "-1.#JIND0000" on windows. Now when float8in() getting call for such value on windows it ending up with error "invalid input syntax for type double precision:" as strtod() not able to understand such values.
I added to check into pgstatindex() to avoid "0/0" situation and issue got fixed.
PFA patch for the same.
Thanks,
Rushabh Lathia
EnterpriseDB Corporation
The Enterprise Postgres Company
Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb
Attachment
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> After debugging I noticed that "0/0" returning NaN on linux but it returns
> "-1.#JIND0000" on windows.
[ rolls eyes ]
> I added to check into pgstatindex() to avoid "0/0" situation and issue got
> fixed.
Hmm. I agree we need to avoid executing 0/0 here, but should we force
the result to 0, or to NaN?
regards, tom lane
Re: Windows env returns error while running "select pgstatindex"
From
Euler Taveira de Oliveira
Date:
Em 24-08-2011 11:27, Tom Lane escreveu: > Hmm. I agree we need to avoid executing 0/0 here, but should we force > the result to 0, or to NaN? > If it returns NaN on other platforms, let's be consistent. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte24x7 e Treinamento
Euler Taveira de Oliveira <euler@timbira.com> writes:
> Em 24-08-2011 11:27, Tom Lane escreveu:
>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>> the result to 0, or to NaN?
> If it returns NaN on other platforms, let's be consistent.
I kinda suspect that the NaN behavior was not designed but accidental.
What I'm wondering is whether it's really the "right", sensible,
behavior.
On reflection I suspect it isn't --- it'd bollix sum() or avg()
calculations over the function's results, for instance. But now
I'm not sure zero is the right thing to put in, either.
regards, tom lane
On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Euler Taveira de Oliveira <euler@timbira.com> writes: >> Em 24-08-2011 11:27, Tom Lane escreveu: >>> Hmm. I agree we need to avoid executing 0/0 here, but should we force >>> the result to 0, or to NaN? > >> If it returns NaN on other platforms, let's be consistent. > > I kinda suspect that the NaN behavior was not designed but accidental. > What I'm wondering is whether it's really the "right", sensible, > behavior. > > On reflection I suspect it isn't --- it'd bollix sum() or avg() > calculations over the function's results, for instance. But now > I'm not sure zero is the right thing to put in, either. It's not very sensible to sum() or avg() such values from different tables, but if you did wish to do so it would be easy enough to shove a CASE statement in there to filter out the NaN results. On a blank slate, I might choose to do it differently, but considering that we have numerous releases out in the field that return NaN, I think we should stick with that rather than using this minor bug as an excuse to change the answer on platforms where this isn't already broken. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I kinda suspect that the NaN behavior was not designed but accidental.
>> What I'm wondering is whether it's really the "right", sensible,
>> behavior.
> On a blank slate, I might choose to do it differently, but considering
> that we have numerous releases out in the field that return NaN, I
> think we should stick with that rather than using this minor bug as an
> excuse to change the answer on platforms where this isn't already
> broken.
[ pokes at it... ] Hmm, you're right, everything back to 8.2 produces
NaNs on this test case (at least on IEEE-compliant platforms). I yield
to the "let's emit NaN" viewpoint.
regards, tom lane