Re: Postgresql for cygwin - 3rd

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