fixing REL7_3_STABLE build issues
The attached (new) src/test/regress/expected/geometry_9.out, intended
only for the 7.3 stable branch, allows a clean regression pass on my
FC4 box. I called it that to avoid conflicts with other geometry_n files
on later branches.
The attached patch for contrib/seg/segparse.y allows a clean 7.3 contrib
build. The latter fix looks like one that should be made on the 7.4
branch also - man 3 errno on my box says:
errno is defined by the ISO C standard to be a modifiable lvalue of
type int, and must not be explicitly declared; errno may be a macro.
I'm not sure why 7.4 doesn't choke at the same place, but doing the
Right Thing (tm) should not hurt. In later branches the declaration is
gone altogether, so the problem has disappeared.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
The attached (new) src/test/regress/expected/geometry_9.out, intended
only for the 7.3 stable branch, allows a clean regression pass on my
FC4 box. I called it that to avoid conflicts with other geometry_n files
on later branches.
I'd like to have a more principled approach to fixing the back branches
than "we'll do whatever it takes to have a clean buildfarm board on the
set of machines that happen to have volunteered to run buildfarm on that
branch".
The geometry test has been such a consistent bugaboo that I'd sooner
remove it from the back branch test lists than follow the path your
proposal leads down. I can see we'd need at least one more geometry
instance immediately in the 7.3 branch, and what about 7.2?
The attached patch for contrib/seg/segparse.y allows a clean 7.3 contrib
build. The latter fix looks like one that should be made on the 7.4
branch also - man 3 errno on my box says:
Agreed --- this is outright unportable code. Patched in 7.2-7-4.
(It may be that 7.4 fails to fail on your machine because it's already
included <errno.h> by way of c.h, but the extern is an invitation to
trouble in any case.)
regards, tom lane
On Sat, 16 Jul 2005, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
The attached (new) src/test/regress/expected/geometry_9.out, intended
only for the 7.3 stable branch, allows a clean regression pass on my
FC4 box. I called it that to avoid conflicts with other geometry_n files
on later branches.I'd like to have a more principled approach to fixing the back branches
than "we'll do whatever it takes to have a clean buildfarm board on the
set of machines that happen to have volunteered to run buildfarm on that
branch".
I think the emphasis on the buildfarm (at least for the "principled
approach") is wrong. The policy should be that for any platform all
supported branches should pass all tests unless something is legitimately
broken and cannot be fixed without major surgery. If this was the stated
policy I know more buildfarm members would run the 7.2/3 branches to help
enforce it.
Also getting the regression tests to pass on even older versions(<=7.1)
seems like a waste of time, but ensuring that they at least compile and
start to allow data extraction may not be, as a recent -general thread has
shown.
Kris Jurka
Kris Jurka <books@ejurka.com> writes:
On Sat, 16 Jul 2005, Tom Lane wrote:
I'd like to have a more principled approach to fixing the back branches
than "we'll do whatever it takes to have a clean buildfarm board on the
set of machines that happen to have volunteered to run buildfarm on that
branch".
I think the emphasis on the buildfarm (at least for the "principled
approach") is wrong. The policy should be that for any platform all
supported branches should pass all tests unless something is legitimately
broken and cannot be fixed without major surgery.
I am suggesting that the pre-7.4 geometry test *is* broken, and that
fixing it only for those machines that join the buildfarm is (a)
wrongheaded and (b) a waste of effort. It'll still be broken on an
unknown (but ever-growing due to changes in toolchains) population of
allegedly-supported platforms that happen not to be represented in the
buildfarm.
I agree that fixing compile problems is a worthwhile activity (and
you'll note I applied that part of Andrew's patch). I don't agree that
fixing known-problematic regression tests is a good use of time. We
are not going to learn anything new by keeping geometry enabled in the
back branches, so why not cut our losses?
If you don't like removing it altogether, how about marking it "ignore"
as we do for the "random" test, so that failures are treated as
noncritical?
regards, tom lane
Tom Lane said:
Andrew Dunstan <andrew@dunslane.net> writes:
The attached (new) src/test/regress/expected/geometry_9.out, intended
only for the 7.3 stable branch, allows a clean regression pass on my
FC4 box. I called it that to avoid conflicts with other geometry_n
files on later branches.I'd like to have a more principled approach to fixing the back branches
than "we'll do whatever it takes to have a clean buildfarm board on the
set of machines that happen to have volunteered to run buildfarm on
that branch".The geometry test has been such a consistent bugaboo that I'd sooner
remove it from the back branch test lists than follow the path your
proposal leads down. I can see we'd need at least one more geometry
instance immediately in the 7.3 branch, and what about 7.2?
I have no objection to disabling the geometry tests by default for 7.2 and
7.3. I think you're right to suggest that fixing them is not worth the
bother.
Note that because of the way the buildfarm script works, this failure was
masking the seg errno bogosity. Maybe I should reverse the test order to
make contrib before running and regression tests.
cheers
andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
Note that because of the way the buildfarm script works, this failure was
masking the seg errno bogosity. Maybe I should reverse the test order to
make contrib before running and regression tests.
Seems like that'd just mask a different set of failures.
Is it practical to teach the script to run the tests that depend only on
what you were able to build? I guess reporting the results would get
more complicated ...
regards, tom lane
Tom Lane wrote:
"Andrew Dunstan" <andrew@dunslane.net> writes:
Note that because of the way the buildfarm script works, this failure was
masking the seg errno bogosity. Maybe I should reverse the test order to
make contrib before running and regression tests.Seems like that'd just mask a different set of failures.
Yeah. I think I'd be more concerned by core regression failures than
contrib build failures - especially as they are often likely to have
more far reaching consequences.
Is it practical to teach the script to run the tests that depend only on
what you were able to build? I guess reporting the results would get
more complicated ...
Not easily. It's really not much more on the client side than an
automation layer over existing build and test infrastructure. The script
itself has very little intelligence.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Seems like that'd just mask a different set of failures.
Yeah. I think I'd be more concerned by core regression failures than
contrib build failures - especially as they are often likely to have
more far reaching consequences.
Agreed. I guess that the order of importance of the pieces you have is
build main (this includes building PLs)
run main tests
run PL tests
build contrib
run contrib tests
I'm not sure where the proposed-to-be-added multibyte regression tests
go in this order. On practical grounds I would put them last; I rather
suspect that porting failures in that code will be rare. Could be wrong
though.
It's slightly annoying that the PLs are built as part of the main build;
I would rather run the main tests and then try to build and test the PLs
(that is, the ones that have external dependencies --- plpgsql can be
treated as part of the core for our purposes here). Not sure if it's
worth hacking the makefiles to make that possible.
regards, tom lane
Tom Lane wrote:
Yeah. I think I'd be more concerned by core regression failures than
contrib build failures - especially as they are often likely to have
more far reaching consequences.Agreed. I guess that the order of importance of the pieces you have is
build main (this includes building PLs)
run main tests
run PL tests
build contrib
run contrib tests
That's almost what we do, but it's a bit more complex. Slightly
simplified, the sequence runs something like this (PL checks only run on
HEAD or branches >8.0):
configure
make
make check
cd contrib && make
make install
cd $installdir && bin/initdb --no-locale data
cd $installdir && bin/pg_ctl -D data -w start
make installcheck
cd src/pl && make installcheck
cd contrib && make installcheck
cd $installdir && bin/pg_ctl -D data stop
I'm not sure where the proposed-to-be-added multibyte regression tests
go in this order. On practical grounds I would put them last; I rather
suspect that porting failures in that code will be rare. Could be wrong
though.
Yes, that makes sense. I don't know when I'll get time to make that
happen though.
It's slightly annoying that the PLs are built as part of the main build;
I would rather run the main tests and then try to build and test the PLs
(that is, the ones that have external dependencies --- plpgsql can be
treated as part of the core for our purposes here). Not sure if it's
worth hacking the makefiles to make that possible.
I don't think so.
cheers
andrew