On 25/01/2014 19:23, Andrew Dunstan wrote:
On 01/24/2014 07:50 AM, Marco Atzeri wrote:
Those two issues need to be fixed. And yes, they are regressions from my
Cygwin 1.7.7 setup where they pass consistently, just about every day.
See
<http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>
1.7.7 is 3.5 years hold.
In the mean time we added 64 bit and moved to gcc-4.8.x
No doubt, but that doesn't mean that extra things failing is OK.
Andrew,
I never wrote that.
You don't get to choose which regression tests you're going to pass and
which you're not. Disabling the tests or providing nonsensical results
files are unacceptable. This is a Cygwin behavior issue and needs to be
fixed.
some indication where to look for in the code will help.
Distributing broken binary that crashes after standard rebase, it is
also not acceptable and it is also worst.
Your farm is not testing this case, I presume.
Quite so. But this is not a case of either/or.
No, but I spent a lot of time on understanding that DLLTOLL/DLLWRAP
produce buggy binaries, and that was a CRITICAL failure.
I have now tested the central part of the proposed changes on both old
and new Cygwin installations, and they appear to work.
I'm going to commit them and backpatch back to 9.0, which is where we
currently have buildfarm coverage (and 8.4 will be at EOL in a few
months anyway). That will take care of your rebase issue.
That leaves several issues to be handled:
* LDAP libraries - the way you have proposed surely isn't right. What
we want is something more like this in the Makefile.global.in:
ifeq ($(PORTNAME), cygwin)
libpq_pgport += $(LDAP_LIBS_FE)
endif
I will test in this way. I have no preferance on
the implemented solution.
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
It hangs also stand alone. I guess some race or deadlock issue.
* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?
Tested tsearch with
"export LANG=C" works
"export LANG=C.utf8" fails
"export LANG=it_IT" works
"export LANG=it_IT.utf8" fails
faulty locale or wrong assumption on utf8 implementation ?
Really, for a properly working port all these need to be fixed.
No objection. Step by step
I am available to work on tests regression, but I am not a postgresql
expert so do not expect all the job from my side.
We can help you some, but very few people in the community run Cygwin,
and my time to spend on it is fairly limited.
For the time being, I can run tests and builds.
cheers
andrew
cheers
Marco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
