pg_upgrade and extra_float_digits
in [PgSql]
|
Prev: Unexpected page allocation behavior on insert-onlytables
Next: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff
From: Andrew Dunstan on 15 May 2010 22:42 Bruce Momjian wrote: > FYI, I test pg_upgrade by loading the old cluster's regression database > from a pg_dump output file, then after the upgrade, I dump the > regression database of the new cluster and diff the changes. > > The problem I just encountered is that pg_dump uses > extra_float_digits=-3 for 9.0, while previous releases used '2'. I had > to do hack each server version to get a dump output that would match > without rounding errors --- it did eventually work and validated. > > That sounds like a disaster waiting to happen. The server version is going to affect much more than just this behaviour, surely. Wouldn't it be better to provide a pg_dump option to provide the extra_float_digits setting? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 15 May 2010 22:44 Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > FYI, I test pg_upgrade by loading the old cluster's regression database > > from a pg_dump output file, then after the upgrade, I dump the > > regression database of the new cluster and diff the changes. > > > > The problem I just encountered is that pg_dump uses > > extra_float_digits=-3 for 9.0, while previous releases used '2'. I had > > to do hack each server version to get a dump output that would match > > without rounding errors --- it did eventually work and validated. > > > > > > That sounds like a disaster waiting to happen. The server version is > going to affect much more than just this behaviour, surely. Wouldn't it > be better to provide a pg_dump option to provide the extra_float_digits > setting? FYI, you can't override it with PGOPTIONS because it is set inside the pg_dump binary. I am not sure what you mean by your second sentence. I was just reporting it in case anyone else was trying this for testing. I doubt anyone else is going to try such a thing. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 15 May 2010 22:46 Andrew Dunstan <andrew(a)dunslane.net> writes: > Bruce Momjian wrote: >> FYI, I test pg_upgrade by loading the old cluster's regression database >> from a pg_dump output file, then after the upgrade, I dump the >> regression database of the new cluster and diff the changes. >> >> The problem I just encountered is that pg_dump uses >> extra_float_digits=-3 for 9.0, while previous releases used '2'. I had >> to do hack each server version to get a dump output that would match >> without rounding errors --- it did eventually work and validated. > That sounds like a disaster waiting to happen. The server version is > going to affect much more than just this behaviour, surely. Wouldn't it > be better to provide a pg_dump option to provide the extra_float_digits > setting? What disaster? That's only for test purposes, it has nothing to do with actual data transfer. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 15 May 2010 23:05 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > >> Bruce Momjian wrote: >> >>> FYI, I test pg_upgrade by loading the old cluster's regression database >>> from a pg_dump output file, then after the upgrade, I dump the >>> regression database of the new cluster and diff the changes. >>> >>> The problem I just encountered is that pg_dump uses >>> extra_float_digits=-3 for 9.0, while previous releases used '2'. I had >>> to do hack each server version to get a dump output that would match >>> without rounding errors --- it did eventually work and validated. >>> > > >> That sounds like a disaster waiting to happen. The server version is >> going to affect much more than just this behaviour, surely. Wouldn't it >> be better to provide a pg_dump option to provide the extra_float_digits >> setting? >> > > What disaster? That's only for test purposes, it has nothing to do with > actual data transfer. > > > Maybe I have misunderstood. How exactly is the server version being hacked here? I know it's only for testing, but it still seems to me that lying to a program as heavily version dependant as pg_dump is in general a bad idea. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 15 May 2010 23:12
Andrew Dunstan wrote: > >>> The problem I just encountered is that pg_dump uses > >>> extra_float_digits=-3 for 9.0, while previous releases used '2'. I had > >>> to do hack each server version to get a dump output that would match > >>> without rounding errors --- it did eventually work and validated. > >>> > > > > > >> That sounds like a disaster waiting to happen. The server version is > >> going to affect much more than just this behaviour, surely. Wouldn't it > >> be better to provide a pg_dump option to provide the extra_float_digits > >> setting? > >> > > > > What disaster? That's only for test purposes, it has nothing to do with > > actual data transfer. > > > > > > > > Maybe I have misunderstood. How exactly is the server version being > hacked here? I know it's only for testing, but it still seems to me that > lying to a program as heavily version dependant as pg_dump is in general > a bad idea. The code in pg_dump 9.0 is: /* * If supported, set extra_float_digits so that we can dump float data * exactly (given correctly implemented float I/O code, anyway) */ if (g_fout->remoteVersion >= 90000) do_sql_command(g_conn, "SET extra_float_digits TO 3"); else if (g_fout->remoteVersion >= 70400) --> do_sql_command(g_conn, "SET extra_float_digits TO 2"); The indicated line had to be changed to '3'. I did not change anything else, and it was only done in my private CVS tree. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |