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>Attachments:
regression.diffsapplication/octet-stream; name=regression.diffsDownload
*** ./expected/join.out Thu Sep 25 16:58:06 2003
--- ./results/join.out Tue Feb 24 21:39:26 2004
***************
*** 216,223 ****
-----+---+----
| 0 |
| 1 | -1
- | 2 | 2
| 2 | 4
| 3 | -3
| 5 | -5
| 5 | -5
--- 216,223 ----
-----+---+----
| 0 |
| 1 | -1
| 2 | 4
+ | 2 | 2
| 3 | -3
| 5 | -5
| 5 | -5
***************
*** 1569,1576 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
--- 1569,1576 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
***************
*** 1583,1590 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
--- 1583,1590 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
***************
*** 1625,1632 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
--- 1625,1632 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
***************
*** 1638,1645 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
--- 1638,1645 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
***************
*** 1662,1669 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
--- 1662,1669 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
***************
*** 1678,1685 ****
-----+---+---+-------+---+----
| 0 | | zero | 0 |
| 1 | 4 | one | 1 | -1
- | 2 | 3 | two | 2 | 2
| 2 | 3 | two | 2 | 4
| 3 | 2 | three | 3 | -3
| 5 | 0 | five | 5 | -5
| 5 | 0 | five | 5 | -5
--- 1678,1685 ----
-----+---+---+-------+---+----
| 0 | | zero | 0 |
| 1 | 4 | one | 1 | -1
| 2 | 3 | two | 2 | 4
+ | 2 | 3 | two | 2 | 2
| 3 | 2 | three | 3 | -3
| 5 | 0 | five | 5 | -5
| 5 | 0 | five | 5 | -5
***************
*** 1723,1730 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
--- 1723,1730 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
***************
*** 1732,1739 ****
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
- | | | null |
| | 0 | zero |
(13 rows)
SELECT '' AS "xxx", *
--- 1732,1739 ----
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
| | 0 | zero |
+ | | | null |
(13 rows)
SELECT '' AS "xxx", *
***************
*** 1743,1750 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
--- 1743,1750 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
***************
*** 1752,1759 ****
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
- | | | null |
| | 0 | zero |
(13 rows)
SELECT '' AS "xxx", *
--- 1752,1759 ----
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
| | 0 | zero |
+ | | | null |
(13 rows)
SELECT '' AS "xxx", *
***************
*** 1762,1774 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
- | | | |
| | | | 0
(9 rows)
SELECT '' AS "xxx", *
--- 1762,1774 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
| | | | 0
+ | | | |
(9 rows)
SELECT '' AS "xxx", *
***************
*** 1777,1789 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
- | | | |
| | | | 0
(9 rows)
SELECT '' AS "xxx", *
--- 1777,1789 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 5 | 0 | five | -5
| 5 | 0 | five | -5
| | | | 0
+ | | | |
(9 rows)
SELECT '' AS "xxx", *
======================================================================
*** ./expected/rules.out Thu Dec 18 19:09:14 2003
--- ./results/rules.out Tue Feb 24 21:39:41 2004
***************
*** 1124,1131 ****
SELECT * FROM shoelace_obsolete;
sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm
------------+----------+------------+--------+----------+-----------
- sl9 | 0 | pink | 35 | inch | 88.9
sl10 | 1000 | magenta | 40 | inch | 101.6
(2 rows)
SELECT * FROM shoelace_candelete;
--- 1124,1131 ----
SELECT * FROM shoelace_obsolete;
sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm
------------+----------+------------+--------+----------+-----------
sl10 | 1000 | magenta | 40 | inch | 101.6
+ sl9 | 0 | pink | 35 | inch | 88.9
(2 rows)
SELECT * FROM shoelace_candelete;
======================================================================
*** ./expected/stats.out Sat Nov 1 14:18:20 2003
--- ./results/stats.out Tue Feb 24 21:42:09 2004
***************
*** 62,68 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! t | t | t | t
(1 row)
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
--- 62,68 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! f | f | f | f
(1 row)
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
***************
*** 71,77 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
! t | t
(1 row)
-- clean up
--- 71,77 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
! f | f
(1 row)
-- clean up
======================================================================
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
I will look at c) unless someone comes up with a better idea
or someone else gets in first.
That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public domain... needs a
closer look that I've given it, but might be a good starting point.
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>Import Notes
Resolved by subject fallback
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 win32None 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
I will look at c) unless someone comes up with a better idea
or someone else gets in first.That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public
domain... needs a closer look that I've given it, but might be a
good starting point.
For the heck of it, I went and wedged this file into the source base, and
got this:
=======================
3 of 94 tests failed.
=======================
The 7 tests which failed due to timestamp now pass, leaving the three
failures listed in the original post. I don't know about you, but I'm sure
set on option (c) now :-)
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>Import Notes
Resolved by subject fallback
"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
Hi Everyone,
I'm not sure of the detail behind winsup/cygwin/localtime.cc, but there are
problems with how Cygwin handles dates and times on Windows.
See http://www.cygwin.com/ml/cygwin/2003-07/msg01016.html.
If there is any relevance, I think it is imperative that the Win32 version
of PostgreSQL links directly to the system clock and avoids this Cygwin bug.
Regards,
George
----- Original Message -----
From: "Claudio Natoli" <claudio.natoli@memetrics.com>
To: "'Andrew Dunstan'" <andrew@dunslane.net>;
<pgsql-hackers-win32@postgresql.org>; <pgsql-hackers@postgresql.org>
Sent: Tuesday, February 24, 2004 6:52 AM
Subject: Re: [pgsql-hackers-win32] [HACKERS] Win32 regression test status
I will look at c) unless someone comes up with a better idea
or someone else gets in first.That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public domain... needs
a
closer look that I've given it, but might be a good starting point.
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
Show quoted text
ailpolicy.html</a>
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
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
George Weaver wrote:
I'm not sure of the detail behind winsup/cygwin/localtime.cc, but there are
problems with how Cygwin handles dates and times on Windows.See http://www.cygwin.com/ml/cygwin/2003-07/msg01016.html.
If there is any relevance, I think it is imperative that the Win32 version
of PostgreSQL links directly to the system clock and avoids this Cygwin bug.
Not the same problem.
cheers
andrew
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.dataFWIW, "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 19073Attachments:
/bjm/difftext/plainDownload
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' \