Regression test status (was type coersion)

... all of the
regression tests pass, except for the select_view test, which has
been core dumping for weeks. Anyone else seeing that?

I ... ran the regression
tests for the first time in a long time. select_views works fine for
me, but there are several other tests that look badly broken:
I'm on HP-UX 9.03, PA-RISC 1.1, gcc 2.7.2.2 if that helps.

Hmm. I'm on Linux-libc5, i686, gcc 2.7.2.1, and select_views is still
core dumping:

QUERY: SELECT * FROM toyemp WHERE name = 'sharon';
pqReadData() -- backend closed the channel unexpectedly.

--- results/select_implicit.out Sat Aug 15 13:44:16 1998
--- results/select_having.out   Sat Aug 15 13:44:16 1998

These two pass on my machine. Your select_having result looks similar to
the sorting results back when the in-memory/on-disk sorting routines
were broken; some identical values are not getting grouped together
while others are.

--- results/random.out  Sat Aug 15 13:44:19 1998
QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR:  can't look up operator 713

Ah. I am getting failures on this too but didn't actually look at why,
just assuming that the randomizer was doing better nowadays. This is
probably related to something I, or possibly Bruce or David, had done.
If you change the query to

SELECT count(*) FROM onek where oidrand(onek.oid, 10) = TRUE;

then it works. I'll look at it. Darn, I had just stripped out the
debugging stuff in the code before submitting it, since leaving it
hanging around was annoying Bruce (with good reason btw).

- Tom

--- results/random.out  Sat Aug 15 13:44:19 1998
QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR:  can't look up operator 713

Ah. I am getting failures on this too but didn't actually look at why,
just assuming that the randomizer was doing better nowadays. This is
probably related to something I, or possibly Bruce or David, had done.

OK, I just committed patches which fixes this problem. The index
strategy code used to just check for an available operator, but I had
changed it to try an alternate strategy by looking for the same operator
with different types. But the same code gets executed even if the
restriction clause is just a function returning a boolean, with no
operator involved at all.

I now allow the operator name lookup to return a null pointer if an
alternate does not exist, and then the code stops looking for
alternatives.

So now the "random" test still fails, but in a good way with the
expected results...

- Tom

Tom Lane wrote:

I rebuilt the system from current sources today, and ran the regression
tests for the first time in a long time. select_views works fine for
me, but there are several other tests that look badly broken:
SELECT ... ORDER BY upper(c) is misordering the results in select_implicit,
GROUP BY
regards, tom lane

*** expected/select_implicit.out        Sat Aug 15 11:56:03 1998
--- results/select_implicit.out Sat Aug 15 13:44:16 1998
***************
*** 213,226 ****
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
- 1
2
3
4
5
6
- 7
8
9
0
(10 rows)
--- 213,226 ----
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
2
+ 1
3
4
5
6
8
+ 7
9
0
(10 rows)

Interesting. I do not recall my exact data set in the regression, but I
believe both results are correct. In some sense, on your machine
upper('CCCC') and upper('cccc') are sorting in a different order then my
machine. I realize that internally they are actually ordinally tied. But I
thought they should still produce a predictable, uniform, result set. Either,
there is a bug or I need more reliable test data. I will verify this when I
get home.

Do any of these problems still exist?

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

... all of the
regression tests pass, except for the select_view test, which has been
core dumping for weeks. Anyone else seeing that, or is it just me? :(

I rebuilt the system from current sources today, and ran the regression
tests for the first time in a long time. select_views works fine for
me, but there are several other tests that look badly broken:
SELECT ... ORDER BY upper(c) is misordering the results in select_implicit,
GROUP BY on a datetime is not working right in select_having, and the
random test is failing because it "can't look up operator 713".

I'm on HP-UX 9.03, PA-RISC 1.1, gcc 2.7.2.2 if that helps.

regards, tom lane

*** expected/select_implicit.out	Sat Aug 15 11:56:03 1998
--- results/select_implicit.out	Sat Aug 15 13:44:16 1998
***************
*** 213,226 ****
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
- 1
2
3
4
5
6
- 7
8
9
0
(10 rows)
--- 213,226 ----
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
2
+ 1
3
4
5
6
8
+ 7
9
0
(10 rows)

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

*** expected/select_having.out	Wed Jul  8 10:29:09 1998
--- results/select_having.out	Sat Aug 15 13:44:16 1998
***************
*** 2,12 ****
GROUP BY d1 HAVING count(*) > 1;
d1                          |count
----------------------------+-----
! Thu Jun 13 00:00:00 1957 PDT|    2
! Mon Feb 10 09:32:01 1997 PST|    3
! Mon Feb 10 17:32:01 1997 PST|   13
Sun Feb 16 17:32:01 1997 PST|    2
Sat Mar 01 17:32:01 1997 PST|    2
! invalid                     |    2
! (6 rows)

--- 2,13 ----
GROUP BY d1 HAVING count(*) > 1;
d1                          |count
----------------------------+-----
! Thu Jun 13 00:00:00 1957 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    4
! Mon Feb 10 09:32:01 1997 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    7
Sun Feb 16 17:32:01 1997 PST|    2
Sat Mar 01 17:32:01 1997 PST|    2
! (7 rows)

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

*** expected/random.out	Tue Apr 29 10:23:40 1997
--- results/random.out	Sat Aug 15 13:44:19 1998
***************
*** 5,18 ****
(1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! count
! -----
! 92
! (1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! count
! -----
! 98
! (1 row)

--- 5,12 ----
(1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR: can't look up operator 713

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR: can't look up operator 713

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

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

then it works. I'll look at it. Darn, I had just stripped out the
debugging stuff in the code before submitting it, since leaving it
hanging around was annoying Bruce (with good reason btw).

I have an idea on this. If we change #ifdef PARSEDEBUG to something
else, I think we can keep it. If in an include file we say:

#ifdef PARSEDEBUG
#define ParseDebug(x) x
#else
#define ParseDebug(x)
#endif

we can then do

x=3;
y=4;
ParseDebug(printf("test));

and it will look good, and we can always enable it. What do you think?
I can do it if you want?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tom,

I was never able to reproduce the ORDER BY anomaly on my Linux box. I will try
to reproduce it on my AIX box. I have some porting issues I need to get through
first.

In the mean time, if you still see a problem, could you run the query as:
SELECT a, upper(c) FROM test_missing_target ORDER BY upper;
to eliminate the junkfilter as a culprit.

Bruce Momjian wrote:

I check two these of these problems. Read ahead --->

Bruce Momjian wrote:

Do any of these problems still exist?

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

... all of the
regression tests pass, except for the select_view test, which has been
core dumping for weeks. Anyone else seeing that, or is it just me? :(

I rebuilt the system from current sources today, and ran the regression
tests for the first time in a long time. select_views works fine for
me, but there are several other tests that look badly broken:
SELECT ... ORDER BY upper(c) is misordering the results in select_implicit,
GROUP BY on a datetime is not working right in select_having, and the
random test is failing because it "can't look up operator 713".

I'm on HP-UX 9.03, PA-RISC 1.1, gcc 2.7.2.2 if that helps.

regards, tom lane

*** expected/select_implicit.out      Sat Aug 15 11:56:03 1998
--- results/select_implicit.out       Sat Aug 15 13:44:16 1998
***************
*** 213,226 ****
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
- 1
2
3
4
5
6
- 7
8
9
0
(10 rows)
--- 213,226 ----
QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
a
-
2
+ 1
3
4
5
6
8
+ 7
9
0
(10 rows)

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

Both sort orders are correct. I seems that different machines are resolving
equivalent strings differently. I got the same result as Tom on an RS/6000
box. I could be an big vs little endian, signed vs unsigned chars issue. In
any case, the actual sort order is indeterminate. Therefore I will submit a new
regression test with reliable test data.

*** expected/select_having.out        Wed Jul  8 10:29:09 1998
--- results/select_having.out Sat Aug 15 13:44:16 1998
***************
*** 2,12 ****
GROUP BY d1 HAVING count(*) > 1;
d1                          |count
----------------------------+-----
! Thu Jun 13 00:00:00 1957 PDT|    2
! Mon Feb 10 09:32:01 1997 PST|    3
! Mon Feb 10 17:32:01 1997 PST|   13
Sun Feb 16 17:32:01 1997 PST|    2
Sat Mar 01 17:32:01 1997 PST|    2
! invalid                     |    2
! (6 rows)

--- 2,13 ----
GROUP BY d1 HAVING count(*) > 1;
d1                          |count
----------------------------+-----
! Thu Jun 13 00:00:00 1957 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    4
! Mon Feb 10 09:32:01 1997 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    2
! Mon Feb 10 17:32:01 1997 PST|    7
Sun Feb 16 17:32:01 1997 PST|    2
Sat Mar 01 17:32:01 1997 PST|    2
! (7 rows)

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

These results are also correct. Somewhat. I do not know much about datatime
porting issues, but if I do a:
SELECT d1 FROM DATETIME_TBL
I get time reported to the 1/100 of a second. If GROUP BY d1 the hundredths
are not shown. Thus, the counts and groupings are correct. Its just not
showing the hundredths portion.

*** expected/random.out       Tue Apr 29 10:23:40 1997
--- results/random.out        Sat Aug 15 13:44:19 1998
***************
*** 5,18 ****
(1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! count
! -----
! 92
! (1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! count
! -----
! 98
! (1 row)

--- 5,12 ----
(1 row)

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR: can't look up operator 713

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR: can't look up operator 713

Don't know about this one.

David Hartwig <daveh@insightdist.com> writes:

Both sort orders are correct. I seems that different machines are
resolving equivalent strings differently. I got the same result as
Tom on an RS/6000 box. I could be an big vs little endian, signed vs
unsigned chars issue. In any case, the actual sort order is
indeterminate. Therefore I will submit a new regression test with
reliable test data.

OK.

These results are also correct. Somewhat. I do not know much about
datatime porting issues, but if I do a:
SELECT d1 FROM DATETIME_TBL
I get time reported to the 1/100 of a second. If GROUP BY d1 the
hundredths are not shown. Thus, the counts and groupings are correct.
Its just not showing the hundredths portion.

The issue here is why you (or whoever it was prepared the regression
test) got different results from me...

QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
! ERROR: can't look up operator 713

Don't know about this one.

That bug should be fixed in the current sources, I believe.

regards, tom lane

Tom Lane wrote:

These results are also correct. Somewhat. I do not know much about
datatime porting issues, but if I do a:
SELECT d1 FROM DATETIME_TBL
I get time reported to the 1/100 of a second. If GROUP BY d1 the
hundredths are not shown. Thus, the counts and groupings are correct.
Its just not showing the hundredths portion.

The issue here is why you (or whoever it was prepared the regression
test) got different results from me...

I do get the same results - on my RS/6000. And I did not prepare the
test. But, to be more precise:

1. The failure does not indicate any problems w/ the HAVING clause.

2. This test will never work if there is a machine dependence on the
ability to resolve datatime down to the 1/100 second.

3. There appears to be something strange going on in the way GROUPed BY
datetime columns do not display the 1/100 portion of seconds. Is this a
known problem?

Unless someone objects, I will submit a test suit to, at least remove the
false reading on select_having.