Re: [BUG] Denormal float values break backup/restore

From: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUG] Denormal float values break backup/restore
Date: 2011-06-11 19:08:29
Message-ID: 4DF3BD2D.5020800@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2011-06-11 01:57, Tom Lane wrote:

> (5) Lobby your libc providers to make strtod accept denormals without
> throwing ERANGE. There is no obvious reason why it shouldn't. (On at
> least one of my boxes, it does.)

The standard either explicitly allows or requires this behaviour
(depending on which text I look at) for underflow.

AIUI that is defined to be a little vague, but includes denormalized
numbers that would undergo any rounding at all. It says that on
overflow the conversion should return the appropriate HUGE_VAL variant,
and set ERANGE. On underflow it returns a reasonably appropriate value
(and either may or must set ERANGE, which is the part that isn't clear
to me).

ISTM the appropriate response to ERANGE combined with a "small" return
value is to either ignore or report the rounding error, but accept the
return value. The current code in float.c doesn't check the return
value at all and treats all ERANGE conditions as equal.

Jeroen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2011-06-11 19:21:46 Re: pgbench--new transaction type
Previous Message Tom Lane 2011-06-11 19:03:18 Re: Identifying no-op length coercions