Hi all,

my next TODO item for the Win32 port was to try to bring all the regression
tests up. 

Pleased to report that, with a great deal of hackage + kludges (which I hope
to refine and submit as patches for review over the next couple weeks), all
but 10 tests pass!

7 of these fail pretty much *only* due to localtime returning NULL for
pre-1970 dates, specifically: date, timestamp, timestampz, abstime,
tinterval, horology, arrays. To resolve this, seems like there are 3
solutions:

a) Provide "post-1970-only" versions of the expected regression test output,
for use under win32
b) Remove pre-1970 dates from *all* regression test files
c) Code up "pg_localtime" for win32

None of these are appealing, particularly b). Any better ideas?


With this issue aside, that leaves three tests remaining for examination:
join, rules and stats. The regression diffs are attached. 

The join and rules failures don't look material, AFAICS, as the right rows
are returned, just not necessarily in the expected order... is this an
issue? Is the order mandated in these cases. Again, afaIcs, it isn't, but
strictly I'm out of my depth here.

This leaves the stats test as possibly the only real remaining failure. An
analysis (collector not running?) based on the diff would be appreciated, as
well as pointers to which lines of code/functions one would expect to see
invoked if this test was running correctly, to help debugging.

Cheers,
Claudio


--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
Tue, 24 Feb 2004 22:11:05 +1100
Claudio Natoli <claudio.natoli@memetrics.com>
Win32 regression test status
Hi,

On Tuesday 24 February 2004 12:11, Claudio Natoli wrote:
> Hi all,
>
> my next TODO item for the Win32 port was to try to bring all the regression
> tests up.
>
> Pleased to report that, with a great deal of hackage + kludges (which I
> hope to refine and submit as patches for review over the next couple
> weeks), all but 10 tests pass!
>
[...]

Great to hear!

Just as a side node: as part of a computer camp I downloaded the nightly 
snapshot of 2004-21-02, installed MinGW/MSYS, grabbed some external flex and 
went away compiling/installing. Worked quite well, apart from some small 
configure-foo and hand-flexing ;-)

Then, started the thing up (on XP Prof) and run a load test from a real-world 
customer app. Performance was acceptable for an early port, but the 
postmaster/backends kept crashing during this test. A small survey showed 
that the backends grabbed more and more mem, and the crashed when the memory 
exceeded some barrier, roughly 12-13 MB.

Is this known? Worth to sort it out? It has to be noted, that when the clients 
re-connected periodically (20 simultaneously) all went well, and I never lost 
_ANY_ data!

So far, congrats!

Joe
-- 
Leading SW developer  - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW:  http://www.sea-gmbh.com


Tue, 24 Feb 2004 12:42:10 +0100
Joerg Hessdoerfer <Joerg.Hessdoerfer@sea-gmbh.com>
Re: [HACKERS] Win32 regression test status
Claudio Natoli said:
>
>
> 7 of these fail pretty much *only* due to localtime returning NULL for
> pre-1970 dates, specifically: date, timestamp, timestampz, abstime,
> tinterval, horology, arrays. To resolve this, seems like there are 3
> solutions:
>
> a) Provide "post-1970-only" versions of the expected regression test
> output, for use under win32
> b) Remove pre-1970 dates from *all* regression test files
> c) Code up "pg_localtime" for win32
>
> None of these are appealing, particularly b). Any better ideas?
>

I don't think a) and b) are options at all - pre-1970 dates have to work
as expected.

I will look at c) unless someone comes up with a better idea or someone
else gets in first.

cheers

andrew



Tue, 24 Feb 2004 07:58:33 -0500 (EST)
"Andrew Dunstan" <andrew@dunslane.net>
Re: [HACKERS] Win32 regression test status
"Andrew Dunstan" <andrew@dunslane.net> writes:
> Claudio Natoli said:
>> a) Provide "post-1970-only" versions of the expected regression test
>> output, for use under win32
>> b) Remove pre-1970 dates from *all* regression test files
>> c) Code up "pg_localtime" for win32

> I don't think a) and b) are options at all - pre-1970 dates have to work
> as expected.

(b) is *not* an option.  We are not dumbing down our standards to
accommodate Win32.  It's bad enough that some of our platforms don't
support DST handling before 1970.  I suppose (a) is an acceptable
option if we think that Windoze users are accustomed to the idea that
they can't store dates before 1970.

The long-term solution we have talked about before is to stop depending
on libc's time library entirely, and write our own date/timezone code,
thereby getting rid of all the woolly vagaries of time support on
different platforms, not to mention the fundamental design mistakes made
in the libc time API (like the fact that there's no defined way to test
whether a timezone name is valid).  Perhaps it would be better to expend
effort on that, instead of doing the quick kluge that I think was meant
by (c).

			regards, tom lane

Tue, 24 Feb 2004 10:19:56 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Win32 regression test status 
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> The join and rules failures don't look material, AFAICS, as the right rows
> are returned, just not necessarily in the expected order... is this an
> issue? Is the order mandated in these cases. Again, afaIcs, it isn't, but
> strictly I'm out of my depth here.

It's not mandated but we need to know why this platform acts differently
from the rest.  The join failures look like it may be an issue of the
qsort() implementation acting differently for equal keys than most do.
Not sure whether the same applies to rules.

> This leaves the stats test as possibly the only real remaining failure. An
> analysis (collector not running?) based on the diff would be
> appreciated,

Not running or not receiving data, likely.  You could perhaps attach to
the stats collector process with a debugger and watch to see if it's
doing anything.

			regards, tom lane

Tue, 24 Feb 2004 10:32:57 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Win32 regression test status 
Patch attached and applied.  Thanks.

---------------------------------------------------------------------------

> Adds the -W flag to the pwd call under Win32. This allows directories,
> which are munged by sed, such as:
> /e/cygwin/opt/diff9c/pgsql/src/test/regress/data/agg.data to be
> correctly passed as:
> e:/cygwin/opt/diff9c/pgsql/src/test/regress/data/agg.data
> 
> FWIW, "fixes" a large (> 20) tests under Win32.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/test/regress/GNUmakefile
===================================================================
RCS file: /cvsroot/pgsql-server/src/test/regress/GNUmakefile,v
retrieving revision 1.45
diff -c -c -r1.45 GNUmakefile
*** src/test/regress/GNUmakefile	23 Dec 2003 21:56:21 -0000	1.45
--- src/test/regress/GNUmakefile	3 Mar 2004 04:20:11 -0000
***************
*** 73,80 ****
--- 73,86 ----
  
  all: $(input_files) $(output_files)
  
+ ifneq ($(PORTNAME),win32)
  abs_srcdir := $(shell cd $(srcdir) && pwd)
  abs_builddir := $(shell pwd)
+ else
+ abs_srcdir := $(shell cd $(srcdir) && pwd -W)
+ abs_builddir := $(shell pwd -W)
+ endif
+ 
  
  define sed-command
  sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \
Tue, 2 Mar 2004 23:22:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Win32 regression fix