Thread: Win32 regression tests
Hi all,
the win32 port is now at the stage (with the pending patches) where a
surprising number of the tests pass (or would pass if not for the
differences in %e/%g printing and the pre-1970 localtime issues, discussed
previously).
However, a number of tests fail purely because, for some reason, ERROR
messages seem to get printed out at the end of the test, instead of where
expected, and sometimes with an extra blank line. I've included a few
examples below.
Anyway care to hazard a guess as to what the cause could be, and how to
correct?
Cheers,
Claudio
*** ./expected/boolean.out Sun Sep 28 23:10:44 2003
--- ./results/boolean.out Thu Feb 5 13:53:22 2004
***************
*** 112,118 ****
-- For pre-v6.3 this evaluated to false - thomas 1997-10-23
INSERT INTO BOOLTBL2 (f1)
VALUES (bool 'XXX');
- ERROR: invalid input syntax for type boolean: "XXX"
-- BOOLTBL2 should be full of false's at this point
SELECT '' AS f_4, BOOLTBL2.*;
f_4 | f1
--- 125,130 ----
***************
*** 277,279 ****
--- 302,305 ----
--
DROP TABLE BOOLTBL1;
DROP TABLE BOOLTBL2;
+ ERROR: invalid input syntax for type boolean: "XXX"
======================================================================
*** ./expected/char_1.out Tue May 14 23:05:43 2002
--- ./results/char.out Thu Feb 5 13:53:22 2004
***************
*** 23,29 ****
INSERT INTO CHAR_TBL (f1) VALUES ('');
-- try char's of greater than 1 length
INSERT INTO CHAR_TBL (f1) VALUES ('cd');
- ERROR: value too long for type character(1)
INSERT INTO CHAR_TBL (f1) VALUES ('c ');
SELECT '' AS seven, CHAR_TBL.*;
seven | f1
--- 24,29 ----
***************
*** 109,115 ****
INSERT INTO CHAR_TBL (f1) VALUES ('ab');
INSERT INTO CHAR_TBL (f1) VALUES ('abcd');
INSERT INTO CHAR_TBL (f1) VALUES ('abcde');
- ERROR: value too long for type character(4)
INSERT INTO CHAR_TBL (f1) VALUES ('abcd ');
SELECT '' AS four, CHAR_TBL.*;
four | f1
--- 116,121 ----
***************
*** 120,122 ****
--- 126,131 ----
| abcd
(4 rows)
+
+ ERROR: value too long for type character(1)
+ ERROR: value too long for type character(4)
======================================================================
*** ./expected/varchar_1.out Tue May 14 23:05:43 2002
--- ./results/varchar.out Thu Feb 5 13:53:23 2004
***************
*** 12,18 ****
INSERT INTO VARCHAR_TBL (f1) VALUES ('');
-- try varchar's of greater than 1 length
INSERT INTO VARCHAR_TBL (f1) VALUES ('cd');
- ERROR: value too long for type character varying(1)
INSERT INTO VARCHAR_TBL (f1) VALUES ('c ');
SELECT '' AS seven, VARCHAR_TBL.*;
seven | f1
--- 12,17 ----
***************
*** 98,104 ****
INSERT INTO VARCHAR_TBL (f1) VALUES ('ab');
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcd');
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcde');
- ERROR: value too long for type character varying(4)
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcd ');
SELECT '' AS four, VARCHAR_TBL.*;
four | f1
--- 104,109 ----
***************
*** 109,111 ****
--- 114,119 ----
| abcd
(4 rows)
+
+ ERROR: value too long for type character varying(1)
+ ERROR: value too long for type character varying(4)
---
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>
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> However, a number of tests fail purely because, for some reason, ERROR
> messages seem to get printed out at the end of the test, instead of where
> expected, and sometimes with an extra blank line. I've included a few
> examples below.
> Anyway care to hazard a guess as to what the cause could be, and how to
> correct?
Lack of fflush(stderr) maybe? On Unix systems stderr is line-buffered
and so it's seldom necessary to fflush it, but perhaps Windows gets this
wrong (yawn...).
regards, tom lane
Tom Lane wrote: >Claudio Natoli <claudio.natoli@memetrics.com> writes: > > >>However, a number of tests fail purely because, for some reason, ERROR >>messages seem to get printed out at the end of the test, instead of where >>expected, and sometimes with an extra blank line. I've included a few >>examples below. >> >> > > > >>Anyway care to hazard a guess as to what the cause could be, and how to >>correct? >> >> > >Lack of fflush(stderr) maybe? On Unix systems stderr is line-buffered >and so it's seldom necessary to fflush it, but perhaps Windows gets this >wrong (yawn...). > > > Or unbuffered. On Linux "man setbuf " says: The standard error stream stderr is always unbuffered by default. Perhaps on Windows we should put a call to "setbuf(stderr,NULL)" somewhere right at the beginning of each program. cheers andrew
Tom Lane writes:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > However, a number of tests fail purely because, for some reason, ERROR
> > messages seem to get printed out at the end of the test, instead of
where
> > expected, and sometimes with an extra blank line. I've included a few
> > examples below.
>
> > Anyway care to hazard a guess as to what the cause could be, and how to
> > correct?
>
> Lack of fflush(stderr) maybe?
Thanks for the hint. Lead me to try dropping in setvbuf(...,_IONBF,...)
calls, but to no avail.
Turns out it is another ming buffering issue, 'cause if I, say, run "make
installcheck" from Cygwin (with the postmaster running from either the Win32
command prompt, or mingw/msys), there's no such problem. Only occurs when
you run "make (install)check" from within ming/msys itself.
This is going to be really annoying for anyone developing the win32 port, at
least for as long as ming has these issues [sigh].
[On the plus side, the tests are running. "41 of 94 tests failed". Ok ok,
not great, until you do a quick scan over the results and see that almost
all of those that fail are for known issues; minor ones like %g/%e +
localtime differences, and major ones like deadlocking on rename/unlink]
> On Unix systems stderr is line-buffered and so it's seldom necessary to
> fflush it, but perhaps Windows gets this wrong (yawn...).
Then I guess you'll see some humour in the following, straight off the MSDN
for setvbuf:
_IOLBF
For some systems, this provides line buffering. However, for Win32, the
behavior is the same as _IOFBF - Full Buffering.
Again, thanks for the hint :-)
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>