Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-17 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@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.

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-17 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Bruce Momjian
Andrew Dunstan wrote: 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.

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Andrew Dunstan wrote: But do earlier server versions accept a value of 3? The 8.4 docs say The value can be set as high as 2. That is the other thing I had to hack --- the 8.4 backend version had to be changed to accept '3'. The good thing is this has

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Andrew Dunstan
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Andrew Dunstan wrote: But do earlier server versions accept a value of 3? The 8.4 docs say The value can be set as high as 2. That is the other thing I had to hack --- the 8.4 backend version had to be changed to

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Andrew Dunstan
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Bruce Momjian
Andrew Dunstan wrote: 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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Andrew Dunstan
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Tom Lane
Bruce Momjian br...@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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Andrew Dunstan
Tom Lane wrote: Bruce Momjian br...@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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-16 Thread Tom Lane
Andrew Dunstan and...@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

[HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Andrew Dunstan
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Tom Lane
Andrew Dunstan and...@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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan and...@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

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Bruce Momjian
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.

Re: [HACKERS] pg_upgrade and extra_float_digits

2010-05-15 Thread Andrew Dunstan
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: /*