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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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:
/*
19 matches
Mail list logo
