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
>
Tom Lane wrote:
> Bruce Momjian 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.
Andrew Dunstan 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_up
Tom Lane wrote:
Bruce Momjian 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. Yo
Bruce Momjian 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_f
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
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:
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 t
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
> > chan
Tom Lane wrote:
Bruce Momjian 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 g
Bruce Momjian 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 to be d
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
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:
/*
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 valid
Tom Lane wrote:
Andrew Dunstan 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 encounte
Andrew Dunstan 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 p
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 i
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
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 rele
19 matches
Mail list logo
