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 23:22 Bruce Momjian wrote: >> >> 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. > > Oh, I see. It is pg_dump that you hacked. That wasn't clear to me from what you first said. But do earlier server versions accept a value of 3? The 8.4 docs say "The value can be set as high as 2". 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: Andrew Dunstan on 16 May 2010 20:59 Bruce Momjian wrote: > Andrew Dunstan wrote: > >>>> Eventually the idea would be to have the build farm run such tests (with >>>> a properly created dump file) so we can learn quickly if the backend >>>> data format is changed. >>>> >>>> >>> If we're thinking of doing that, it would be better to back-patch the >>> change that allowed '3'. >>> >>> >>> >>> >> Yeah. >> >> It's going to require some fancy dancing to get the buildfarm to do it. >> Each buildfarm run is for a specific branch, and all the built artefacts >> are normally thrown away. I'd have to work out a way of stashing the >> binaries from a build on one branch for use in the pg_upgrade tests in >> the run on another branch. It's doable but could get messy. >> > > Uh, that is not actually a problem. You just need to set > extra_float_digits=-3 to create the dump file, which is only done once > for each major version. You can _load_ that dump file into an > unmodified old cluster and test just fine. I will write up some > instructions in the next few days. > > You are missing the point I was making. A buildfarm run does not normally have available to it any binaries for a version other that the one it is building. There is no notion of a multi-branch buildfarm run. Each run is for a particular branch and is a separate miracle. So I'm not concerned about the structure of the dump file but about what will be used to load it into an old cluster during a buildfarm run. 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: Tom Lane on 16 May 2010 21:50 Bruce Momjian <bruce(a)momjian.us> writes: > Andrew Dunstan wrote: >> It's going to require some fancy dancing to get the buildfarm to do it. >> Each buildfarm run is for a specific branch, and all the built artefacts >> are normally thrown away. > Uh, that is not actually a problem. You just need to set > extra_float_digits=-3 to create the dump file, which is only done once > for each major version. Wrong. In the first place, we're not going to start carrying something as large as a pg_dump of the regression database as part of the source code for the buildfarm. Even if we wanted to, it wouldn't work because the results aren't platform-independent --- there are float differences and probably row ordering differences to worry about. In the second place, it won't "only be done once", unless you imagine that we never change the regression tests for back branches; a casual perusal of the CVS logs will disprove that idea. The only thing that's really going to work here is to generate the dump on the fly. 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: Tom Lane on 16 May 2010 22:44 Andrew Dunstan <andrew(a)dunslane.net> writes: > This whole discussion leads me to the conclusion that we need to look > more imaginatively at our testing regime. When the buildfarm was created > it (via pg_regress) covered a lot of what we needed to test, but that is > becoming less and less true. Not only does pg_upgrade need testing but > we need to devise some sort of automated testing regime for SR and HS, > among other things. pg_regress is showing it's age a bit, I think. The regression tests have never pretended to test more than a fraction of what might be interesting to test. Crash recovery, in particular, has always been interesting and has never been tested in any mechanized way. They don't really exercise concurrent behavior in any meaningful way either. I don't think they're "showing their age" so much as we're starting to get more ambitious about what we would like to have routine testing for. 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 16 May 2010 21:27
Bruce Momjian wrote: > Thank you. I understand now. > > Imagine finding out on the build farm right away when we break binary > compatibility --- that would be cool. > I'm not saying we can't do that, just that it will not be a trivial change. And yes it would be cool, although I hope we would know before we committed such a change that that would be the outcome. 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 |