I have applications that require IEEE floating-point data to remain unchanged to the last bit after a dump/restore cycle. Currently on all our linux systems, pg_dump uses 8 significant figures (FLT_DIG + 2) to dump 32-bit reals and 17 significant figures (DBL_DIG + 2) to dump 64-bit doubles, where FLT_DIG and DBL_DIG are defined in float.h as 6 and 15, respectively, and 2 is the maximum allowed value for extra_float_digits.
While 17 decimal digits are sufficient to guarantee the complete recovery of all 64-bit double values, some 32-bit reals actually require NINE significant figures. For example, the binary real 0x3dcccd70 is converted using 8 significant figures to 0.10000122, which if converted back to binary will become 0x3dcccd71. A general proof for why 9 significant figures are required for 32-bit reals (and 17 for 64-bit doubles) is in Theorem 15 of David Goldberg's "What Every Computer Scientist Should Know About Floating-Point Arithmetic", which is available on the web and as an appendix to Sun's Numerical Computation Guide. I have been running a locally modified postgresql server with extra_float_digits' upper limit increased by one to 3 and a modified pg_dump which sets extra_float_digits to 3; I have verified that the modification does what I need and it does not seem to have any side effect other than providing one more significant figure than needed for double precision binary to decimal conversion. I would like to ask the postgresql development team to consider it for a future release. Thanks, Keh-Cheng Chu Solar Physics Group, Hansen Experimental Physics Lab Stanford University P.S. I run slony with extra_float_digits set to 3 in (my locally modified) postgresql.conf in order to get around the same precision problem. It would be nice if slony would do something similar to pg_dump and enable the extra digits by default; I will bring that up with slony developers if this modification is accepted. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
