Обсуждение: Windows build farm failures
Snake and Bandicoot are still hanging in ECPG-Check at the moment. Killing the dt_test.exe program that the regression tests seem to be running frees it all up to properly report the failure. I don't have time to investigate further at the minute, but for anyone that does, Bandicoot's last run was completed only by killing dt_test.exe, whereas Snakes was a little more random :-) Regards Dave.
On Sun, Sep 24, 2006 at 08:54:35PM +0100, Dave Page wrote: > Snake and Bandicoot are still hanging in ECPG-Check at the moment. > Killing the dt_test.exe program that the regression tests seem to be > running frees it all up to properly report the failure. I don't have > time to investigate further at the minute, but for anyone that does, > Bandicoot's last run was completed only by killing dt_test.exe, whereas > Snakes was a little more random :-) I just had a look at the reports and it seems we have several things going on: 1) libpq gives additional information when not able to connect:could not connect to server: Connection refused (0x0000274D/10061) instead of just: could not connect to server: Connection refused Any idea? 2) Printf "%g" with a double high enough for an exponential output gives a difference in the exponent. This is due to Windowsusing three digits while the Unixes use just two, e.g. e+027 instead of e+27. This double stuff creates so many headaches that I wonder if we better not test it at all in the regression suite. Comments? 3) dt_test had to be killed. Judging from the logs it seems the program hang in either PGTYPESdate_from_asc() or PGTYPEStimestamp_from_asc(). Could someone with a Windows/PostgreSQL setup run this test with debugging symbols and tellme where it hangs? It looks like an endless loop to me, but apparently nothing happens on other archs. 4) snake even stopped building the regression suite: testing sql/indicators.pgc ... make[1]: *** [check] Error 1 make[1]: Leaving directory `/usr/local/build-farm/HEAD/pgsql.4896/src/interfaces/ecpg/test' make: *** [check]Error 2 Was this killed manually too? Or did it stop on its own? I'm surprised there is no output explaning why it stops. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> -----Original Message----- > From: Michael Meskes [mailto:meskes@postgresql.org] > Sent: 25 September 2006 11:57 > To: Dave Page > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Windows build farm failures > > On Sun, Sep 24, 2006 at 08:54:35PM +0100, Dave Page wrote: > > Snake and Bandicoot are still hanging in ECPG-Check at the moment. > > Killing the dt_test.exe program that the regression tests seem to be > > running frees it all up to properly report the failure. I don't have > > time to investigate further at the minute, but for anyone that does, > > Bandicoot's last run was completed only by killing > dt_test.exe, whereas > > Snakes was a little more random :-) > > I just had a look at the reports and it seems we have several things > going on: > > 1) libpq gives additional information when not able to connect: > could not connect to server: Connection refused > (0x0000274D/10061) > instead of just: > could not connect to server: Connection refused > > Any idea? Windows error codes I guess. > 2) Printf "%g" with a double high enough for an exponential > output gives > a difference in the exponent. This is due to Windows using three > digits while the Unixes use just two, e.g. e+027 instead of e+27. > > This double stuff creates so many headaches that I wonder if we > better not test it at all in the regression suite. Comments? > > 3) dt_test had to be killed. Judging from the logs it seems > the program > hang in either PGTYPESdate_from_asc() or > PGTYPEStimestamp_from_asc(). > Could someone with a Windows/PostgreSQL setup run this test with > debugging symbols and tell me where it hangs? It looks like an > endless loop to me, but apparently nothing happens on other archs. Unfortunately I'm one of those people who never, ever managed to get a useful backtrace out of GDB on Windows. The only person I've heard of who actually managed to do it enough to document it was Merlin. > 4) snake even stopped building the regression suite: > testing sql/indicators.pgc ... > make[1]: *** [check] Error 1 > make[1]: Leaving directory > `/usr/local/build-farm/HEAD/pgsql.4896/src/interfaces/ecpg/test' > make: *** [check] Error 2 > > Was this killed manually too? Or did it stop on its own? I'm > surprised there is no output explaning why it stops. It was killed, but I started with some of the sh.exe's before I saw that dt_test.exe was running. I've just killed dt_test.exe (and nothing else) on Snake and Bandicoot, so you should see a new set of results for both. Regards, Dave.
> I just had a look at the reports and it seems we have several > things going on: > > 1) libpq gives additional information when not able to connect: > could not connect to server: Connection refused > (0x0000274D/10061) > instead of just: > could not connect to server: Connection refused > > Any idea? Those are windows errorcodes (same code written in box hex and decimal). Not really sure why we have it different on win32, but it has been like that for ages. > 2) Printf "%g" with a double high enough for an exponential output > gives > a difference in the exponent. This is due to Windows using three > digits while the Unixes use just two, e.g. e+027 instead of > e+27. Yeah, this is known. You'll notice we have extra ouput files for the standard regression tests to deal with this. //Magnus
Michael Meskes <meskes@postgresql.org> writes:
> This double stuff creates so many headaches that I wonder if we
> better not test it at all in the regression suite. Comments?
If you're not prepared to support alternative expected files (as the
main regression tests do), then I think you have little choice.
Floating-point behavior is just too variable across platforms.
However, I wonder whether you shouldn't just bite the bullet and put
in support for alternative expected files.
regards, tom lane