From: Tom Lane <tgl@sss.pgh.pa.us>
To: Samir Magar <samirmagar8@gmail.com>
cc: pgsql-performance@postgresql.org, Swapnil Vaze <swapvaze28@gmail.com>
Subject: Re: out of range error while restore using pgdump
In-reply-to: 
 <CAA=to3iNVdwLnT6sh-5ubwG_-2FASE0yzkERV9XsO69UsCjk9w@mail.gmail.com>
References: 
 <CAA=to3iNVdwLnT6sh-5ubwG_-2FASE0yzkERV9XsO69UsCjk9w@mail.gmail.com>
Comments: In-reply-to Samir Magar <samirmagar8@gmail.com>
	message dated "Mon, 16 Jan 2017 14:50:30 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7679.1484580640.1@sss.pgh.pa.us>
Date: Mon, 16 Jan 2017 10:30:40 -0500
Message-ID: <7680.1484580640@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Samir Magar <samirmagar8@gmail.com> writes:
> pg_restore: [archiver (db)] COPY failed for table "tcb_test": ERROR:
>  "5.40593839802118076e-315" is out of range for type double precision

That's ... weird.  I don't have RHEL7 installed to test, but I don't
see any error for that value on RHEL6 or Fedora 25, which ought to
bracket that version.

I suppose your version of strtod() must be refusing to do gradual
underflow, or else you're running on hardware that doesn't do
IEEE-compliant arithmetic.  But I didn't think RHEL supported any
such hardware (unless maybe it's s/390?).  And I can't find any
documentation suggesting that glibc supports turning off gradual
underflow, either.

Perhaps you're using some extension that fools around with the
hardware floating-point options?

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance