Re: [HACKERS] join regression failure on cygwin

Tom Lane wrote: I wrote: Andrew Dunstan writes: It appears on Googling a bit that the erand48() is buggy in that it requires the seed to have been initialized with srand48() or it will constantly return 0.0. Huh, and that sends us into an infinite loop? I'll take a loo

Re: [HACKERS] join regression failure on cygwin

I wrote: > Andrew Dunstan writes: >> It appears on Googling a bit that the erand48() is buggy in that it >> requires the seed to have been initialized with srand48() or it will >> constantly return 0.0. > Huh, and that sends us into an infinite loop? I'll take a look at that. > Even though it'

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: > It appears on Googling a bit that the erand48() is buggy in that it > requires the seed to have been initialized with srand48() or it will > constantly return 0.0. Huh, and that sends us into an infinite loop? I'll take a look at that. Even though it's surely nonrandom

Re: [HACKERS] join regression failure on cygwin

Tom Lane wrote: I don't personally have a problem with just forcing use of our own erand48 on Cygwin; it's not a lot of code and it would make the behavior of that build more like the MSVC build. But it's curious that such a simple library function is seemingly broken on Cygwin ... especially

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: > I'll work on it, but for now I propose to make the following change to > configure.in and the corresponding change in configure: I believe you can just add AC_LIBOBJ(erand48) in the Cygwin-specific section without touching the other part; that's supposed to be a no-op if

Re: [HACKERS] join regression failure on cygwin

Tom Lane wrote: Andrew Dunstan writes: Tom Lane wrote: Hmm. So we need to figure out how to improve configure's check so that it rejects whatever broken version you've got ... Yeah. Any ideas? I'd hate just to exclude the system erand48 on Cygwin and then find out late

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: > Tom Lane wrote: >> Hmm. So we need to figure out how to improve configure's check so that >> it rejects whatever broken version you've got ... > Yeah. Any ideas? I'd hate just to exclude the system erand48 on Cygwin > and then find out later it's broken on some other a

Re: [HACKERS] join regression failure on cygwin

Tom Lane wrote: Andrew Dunstan writes: Tom Lane wrote: I see it claims to have working erand48, but maybe not so much in reality? Good guess. I removed erand48 from the configure file and added erand48.o to OBJS in src/port/Makefile and it suddenly sailed through.

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: > Tom Lane wrote: >> I see it claims to have working erand48, but maybe not so much in >> reality? > Good guess. I removed erand48 from the configure file and added > erand48.o to OBJS in src/port/Makefile and it suddenly sailed through. Hmm. So we need to figure out ho

Re: [HACKERS] join regression failure on cygwin

Tom Lane wrote: I see it claims to have working erand48, but maybe not so much in reality? Good guess. I removed erand48 from the configure file and added erand48.o to OBJS in src/port/Makefile and it suddenly sailed through. cheers andrew -- Sent via pgsql

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: >> My Cygwin buildfarm member started failing (hanging, in fact) >> recently. It seems to hang consistently in join.sql and the only way I >> can get it to complete is to kill the backend fairly violently. See >>

Re: [HACKERS] join regression failure on cygwin

I wrote: My Cygwin buildfarm member started failing (hanging, in fact) recently. It seems to hang consistently in join.sql and the only way I can get it to complete is to kill the backend fairly violently. See

[HACKERS] join regression failure on cygwin

My Cygwin buildfarm member started failing (hanging, in fact) recently. It seems to hang consistently in join.sql and the only way I can get it to complete is to kill the backend fairly violently. See It lo