Thread: Win32 regression test status
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>
Attachment
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
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
"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
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