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 16 May 2010 22:37 Tom Lane wrote: > 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. > > > 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. 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 17 May 2010 06:11 Tom Lane wrote: > 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 Oh, yea. > 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. Well, it doesn't have to match the regression test output exactly --- it just has to be a valid sample. I never run the regression tests as part of my testing --- I only load my fixed pg_dump output into the old database and dump them from the new, and diff. > The only thing that's really going to work here is to generate the dump > on the fly. Well, to do it on the fly, you need to: use $libdir for regression .so files, not absolute paths change CREATE OR REPLACE LANGUAGE to simple CREAtE for 8.4 run it twice to fix inheritance COPY column ordering deal with extra_float_digits That sounds tricky. -- 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: Bruce Momjian on 17 May 2010 23:27
Bruce Momjian wrote: > Well, to do it on the fly, you need to: > > use $libdir for regression .so files, not absolute paths > change CREATE OR REPLACE LANGUAGE to simple CREAtE for 8.4 > run it twice to fix inheritance COPY column ordering > deal with extra_float_digits > > That sounds tricky. I have added the attached file to CVS to explain the proper pg_upgrade testing method. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com |