Win32 regression fix

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>

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(dot)hessdoerfer(at)sea-gmbh(dot)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(at)dunslane(dot)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(dot)natoli(at)memetrics(dot)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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073