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

Marti Raudsepp <marti(at)juffo(dot)org> writes:
> On Fri, Jun 10, 2011 at 17:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I put this right about on par with the occasional suggestions that we
>> implement our own filesystem.

> I am worried that legitimate calculations can bring the database into
> a state where a backup succeeds, but is no longer restorable.
> Obviously making reliable backups is the job of a database.

Yes, but my point is that Postgres cannot be held accountable for every
misfeature of the platforms we are using. We are not replacing libc any
more than we are replacing the filesystem, or the TCP stack, or several
other components that people have trouble with from time to time. We
don't have the manpower, nor the expertise, to take responsibility for
all that stuff.

> I see four ways to make this work:
> 1. Clamp denormal numbers to 0.0 when stored into a table.
> 2. Throw an error when denormal numbers are stored into a table.
> 3. Use the FTZ (flush-to-zero) FPU mode so denormal values never
> appear. I'm not sure whether this is available on all target
> architectures.
> 4. Change the float4in and float8in functions to accept denormal float
> literals. This has a nice side-effect of enabling full IEEE 754
> floating point range.

Or

(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.)

regards, tom lane