Обсуждение: Re: [HACKERS] Core dump in regression tests.
Thomas A. Szybist <szybist@boxhill.com> > > > > > If I compile backend/catalog with -O2 then the table creation is > ^^^ > > OK. So it looks like it may be indexing.c, even with Bruce's > > recent fixes. > > Do you mean -O0 here? > Yes, a typo, I used -O0 for this dir. > > I managed to get this running on a Solaris box. -O2 was not included > by default (wonder why :)). I got a core dump when running initdb > with -O2. I recompiled indexing.c without -O2, and it is much better. > (I basically get the same results as under Linux.) I get the same > core dumps that Keith is seeing with create function. > > So, both my Sparc boxes are behaving the same. > I've not got round to trying a build on my Solaris 2.6 box yet. I was hoping that someone with something faster than a SPARC 2 would do the biz and get the same results. So we have at least two problems, some code that is tickling a gcc optimiser bug (gcc 2.7.2.1 in my case) and an alignment bug in our code that affects SPARC architecture. I've half a mind to see if there is a later version of gcc that does the optimisation correctly. (rpm format for Redhat 4.2) The "create function" problem is a little harder for me to see a way forward. ( my debugging skills are very few.) Keith.
> The "create function" problem is a little harder for me to see
> a way forward. ( my debugging skills are very few.)
Hmm. Bruce's most recent patches didn't fix my problems on Linux/i686
reported earlier. So I figured I'd try a full build with -O0 just to see
if it helped. Not only did it not help, but I got several other
regression tests failing, some with core dumps which did not crash with
-O2. Weird.
- Tom
> Thomas A. Szybist <szybist@boxhill.com>
> >
> > >
> > > If I compile backend/catalog with -O2 then the table creation is
> > ^^^
> > > OK. So it looks like it may be indexing.c, even with Bruce's
> > > recent fixes.
> >
> > Do you mean -O0 here?
> >
>
> Yes, a typo, I used -O0 for this dir.
>
Can you try:
select * from pg_index;
Crashes here. Not good.
--
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)
> Thomas A. Szybist <szybist@boxhill.com> > > > > > > > > If I compile backend/catalog with -O2 then the table creation is > > ^^^ > > > OK. So it looks like it may be indexing.c, even with Bruce's > > > recent fixes. > > > > Do you mean -O0 here? > > > > Yes, a typo, I used -O0 for this dir. One idea is to track heapDescriptor from CatalogIndexInsert() all the way down into the lower functions. Compile with assert checking, which I assume you are already doing. Add this "Assert(heapDescriptor->natts != 0)" to the function, and in lower functions substitute heapDescriptor with the new variable name it took as a function parameter.) When the assert fails, we can see where it is getting messed up. -- 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)
In message <199809010623.CAA00709@candle.pha.pa.us>, Bruce Momjian writes:
> > Thomas A. Szybist <szybist@boxhill.com>
> > >
> > > >
> > > > If I compile backend/catalog with -O2 then the table creation is
> > > ^^^
> > > > OK. So it looks like it may be indexing.c, even with Bruce's
> > > > recent fixes.
> > >
> > > Do you mean -O0 here?
> > >
> >
> > Yes, a typo, I used -O0 for this dir.
>
> One idea is to track heapDescriptor from CatalogIndexInsert() all the
> way down into the lower functions.
>
> Compile with assert checking, which I assume you are already doing.
>
> Add this "Assert(heapDescriptor->natts != 0)" to the function, and in
> lower functions substitute heapDescriptor with the new variable name it
> took as a function parameter.)
>
> When the assert fails, we can see where it is getting messed up.
>
>
> --
> 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)
>
I don't know if this helps, but here's what I've done so far. I'm now on
a Solaris Box, since the optimization thing seems to be similar to the
Linux Box. Its just easier for me to work on the Solaris Box.
When indexing.c is compiled with -O2, I get a core dump. (Big news.)
The core dump occurs at line 208 of backend/access/common/heaptuple.c.
at this memmove.
{
data = (char *) LONGALIGN(data);
memmove(data, DatumGetPointer(value[i]),
att[i]->attlen);
data += att[i]->attlen;
}
This consistantly happens when tupleDesc->natts is 1. When i = 1 on the
second time on the outer loop, value[1] is something like 2123236.
This is out of range when it gets derefenced, memmove barfs.
I was backtracking and turning on debugging one file at a time, but got
lost in fmgr.c.
I'll insert the asserts like you suggested.
Bruce, I can let you on this machine if you like.
Thanks,
Tom
#0 0xef5d0580 in _memcpy ()
(gdb) bt
#0 0xef5d0580 in _memcpy ()
#1 0x297e0 in DataFill (data=0x1a8e0c "", tupleDesc=0x15dce8, value=0xefffccac,
nulls=0xefffccb0 "", infomask=0xefffc9c6, bit=0x1a8e00 "\003") at heaptuple.c:208
#2 0x2bf24 in index_formtuple (tupleDescriptor=0x15dce8, value=0xefffccac, null=0xefffccb0 "")
at indextuple.c:76
#3 0x3ff40 in btinsert (rel=0x1a8060, datum=0xefffccac, nulls=0xefffccb0 "", ht_ctid=0x1a8858,
heapRel=0x166a38) at nbtree.c:358
#4 0xde1bc in fmgr_c (finfo=0xefffcb70, values=0xefffcb80, isNull=0xefffcb6f "") at fmgr.c:115
#5 0xde7bc in fmgr (procedureId=331) at fmgr.c:286
#6 0x38c3c in index_insert ()
#7 0x4d440 in CatalogIndexInsert ()
#8 0x4a6c4 in AddNewAttributeTuples ()
#9 0x4a968 in heap_create_with_catalog ()
#10 0x51b70 in DefineRelation ()
#11 0xb7884 in ProcessUtility ()
#12 0xb5da8 in pg_exec_query_dest ()
#13 0xb5c9c in pg_exec_query ()
#14 0xb6eb8 in PostgresMain ()
#15 0x9ef90 in DoBackend ()
#16 0x9e9dc in BackendStartup ()
#17 0x9df64 in ServerLoop ()
#18 0x9dab8 in PostmasterMain ()
#19 0x722e4 in main ()
> Thomas A. Szybist <szybist@boxhill.com> > > > > > > > > If I compile backend/catalog with -O2 then the table creation is > > ^^^ > > > OK. So it looks like it may be indexing.c, even with Bruce's > > > recent fixes. > > > > Do you mean -O0 here? > > > > Yes, a typo, I used -O0 for this dir. Can we try a simple -O rather than just -O2 and -O0. Could this be some type of optimizer bug in gcc2/Solaris? Everything is pointing to indexing.c, from both the initdb failure and the create function failure. But I can't see anything wrong in there, and other platforms seem to be OK. Someone mentioned that Solaris does not use -O2 by default, and there may be a good reason for this. The new code is more streamlined from the megapatch, and perhaps the optimizer is now able to do too much optimizing. I don't want to go casting blame other places, but I think gcc that may be the cause, and if it is, we just need to lower the default optimization for those platforms. Let's try adding Assert checking with the configure --enable-cassert option, and compiling with -O rather than -O2 and see what happens. -- 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)
Bruce Momjian wrote:
> > Thomas A. Szybist <szybist@boxhill.com>
> > >
> > > >
> > > > If I compile backend/catalog with -O2 then the table creation is
> > > ^^^
> > > > OK. So it looks like it may be indexing.c, even with Bruce's
> > > > recent fixes.
> > >
> > > Do you mean -O0 here?
> > >
> >
> > Yes, a typo, I used -O0 for this dir.
>
> Can we try a simple -O rather than just -O2 and -O0. Could this be some
> type of optimizer bug in gcc2/Solaris?
>
> Everything is pointing to indexing.c, from both the initdb failure and
> the create function failure. But I can't see anything wrong in there,
> and other platforms seem to be OK.
>
Bruce,
I do not know if this problem is related in any way, but I have a serious
problem on AIX 4.1. I am jumping in here because there is a chance they are
related. Just manifest differently.
If I add an index to a table I can no longer use the table. In essence,
the look up on relname in pg_class fails. If I:
SELECT * FROM pg_class WHERE relname = 'table_i_just_indexed'
-- or \d table_i_just_indexed
I get no results.
SELECT * FROM pg_class
Displays it perfectly. So does:
SELECT * FROM pg_class WHERE relname like '%table_i_just_indexed'
If I manually correct relname:
UPDATE pg_class SET relname = 'table_i_just_indexed' WHERE relname like
'%table_i_just_indexed'
Everything seems to function normally again.
I can not reproduce on my Linux box. Assertions show nothing. This can't be
good.
Andreas, are you having any success?
> > Can we try a simple -O rather than just -O2 and -O0. Could this be some > > type of optimizer bug in gcc2/Solaris? > > > > Everything is pointing to indexing.c, from both the initdb failure and > > the create function failure. But I can't see anything wrong in there, > > and other platforms seem to be OK. > > > > Bruce, > > I do not know if this problem is related in any way, but I have a serious > problem on AIX 4.1. I am jumping in here because there is a chance they are > related. Just manifest differently. > > If I add an index to a table I can no longer use the table. In essence, > the look up on relname in pg_class fails. If I: > SELECT * FROM pg_class WHERE relname = 'table_i_just_indexed' > -- or \d table_i_just_indexed > I get no results. > SELECT * FROM pg_class > Displays it perfectly. So does: > SELECT * FROM pg_class WHERE relname like '%table_i_just_indexed' > If I manually correct relname: > UPDATE pg_class SET relname = 'table_i_just_indexed' WHERE relname like > '%table_i_just_indexed' > Everything seems to function normally again. > > I can not reproduce on my Linux box. Assertions show nothing. This can't be > good. Wow, this is terribly frustrating. All these problems, and I can't reproduce any of them here. I sure hope they all have one cause, and I hope we find the cause soon. -- 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)
> Can we try a simple -O rather than just -O2 and -O0. Could this be
> some type of optimizer bug in gcc2/Solaris?
> Everything is pointing to indexing.c, from both the initdb failure and
> the create function failure. But I can't see anything wrong in there,
> and other platforms seem to be OK.
Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.
There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.
There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.
- Tom
> > Can we try a simple -O rather than just -O2 and -O0. Could this be > > some type of optimizer bug in gcc2/Solaris? > > Everything is pointing to indexing.c, from both the initdb failure and > > the create function failure. But I can't see anything wrong in there, > > and other platforms seem to be OK. > > Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage. > The Sparc platforms will be more sensitive to byte alignment problems, > especially within C structures, so this may be illustrating a > cross-platform problem more clearly. > > There is a repeatable indexing and (perhaps) caching problem I see in > the regression tests. Annoyingly, the problems get slightly worse at the > moment when compiling with -O0. > > There is a fundamental problem lurking somewhere, and there may not be > much point in going beta unless you think that more testers will help to > track down the problem. OK, let me send you my regression output, and perhaps you can see the problem in there so I can debug it. We have a configure problem too, that Tatsuo pointed out. I removed my config.cache, and tried to run configure, and got this. I added 'set -x' to help. + pwd + test -z /usr/ucb:/sbin:/usr/sbin:/bin:/usr/bin:/usr/contrib/bin:/usr/X11/bin:/usr/local/postgres/bin:/usr/local/bin:/usr/local/sbin:.:/usr/local/sbin:.:/usr/local/src/pgsql/pgsql/src + test -f /usr/ucb /sbin /usr/sbin /bin /usr/bin /usr/contrib/bin /usr/X11/bin /usr/local/postgres/bin /usr/local/bin /usr/local/sbin. /usr/local/sbin . /usr/local/src/pgsql/pgsql/src/install-sh test: syntax error: Undefined error: 0 + IFS= + INSTALL= + test -n + echo no no + test -n + test -n + INSTALL=NONE + test NONE = NONE + echo - No Install Script found - aborting. - No Install Script found - aborting. + exit 0 -- 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)
> OK, let me send you my regression output, and perhaps you can see the > problem in there so I can debug it. As far as the beta, I am totally confused about the problems we are having, and I don't know what to suggest. Perhaps you can see the problems in my regression output. > > We have a configure problem too, that Tatsuo pointed out. I removed my > config.cache, and tried to run configure, and got this. I added 'set > -x' to help. > OK, I have fixed the configure problem. The path has to have directories separated by space, not colons. Works now. -- 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)
> > Can we try a simple -O rather than just -O2 and -O0. Could this be
> > some type of optimizer bug in gcc2/Solaris?
> > Everything is pointing to indexing.c, from both the initdb failure and
> > the create function failure. But I can't see anything wrong in there,
> > and other platforms seem to be OK.
>
> Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
> The Sparc platforms will be more sensitive to byte alignment problems,
> especially within C structures, so this may be illustrating a
> cross-platform problem more clearly.
>
> There is a repeatable indexing and (perhaps) caching problem I see in
> the regression tests. Annoyingly, the problems get slightly worse at the
> moment when compiling with -O0.
>
OK, here is my regression output. Do you see anything strange in there?
--
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)
====== int2 ======
--- expected/int2.out Sun Aug 23 11:09:37 1998
+++ results/int2.out Tue Sep 1 23:40:10 1998
@@ -7,7 +7,7 @@
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000');
-ERROR: pg_atoi: error reading "100000": Math result not representable
+ERROR: pg_atoi: error reading "100000": Result too large
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
QUERY: SELECT '' AS five, INT2_TBL.*;
====== int4 ======
--- expected/int4.out Sun Aug 23 11:09:37 1998
+++ results/int4.out Tue Sep 1 23:40:10 1998
@@ -7,7 +7,7 @@
QUERY: INSERT INTO INT4_TBL(f1) VALUES ('2147483647');
QUERY: INSERT INTO INT4_TBL(f1) VALUES ('-2147483647');
QUERY: INSERT INTO INT4_TBL(f1) VALUES ('1000000000000');
-ERROR: pg_atoi: error reading "1000000000000": Math result not representable
+ERROR: pg_atoi: error reading "1000000000000": Result too large
QUERY: INSERT INTO INT4_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
QUERY: SELECT '' AS five, INT4_TBL.*;
====== int8 ======
--- expected/int8.out Sun Aug 23 11:09:38 1998
+++ results/int8.out Tue Sep 1 23:40:10 1998
@@ -6,110 +6,110 @@
QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
QUERY: SELECT * FROM INT8_TBL;
q1| q2
-----------------+-----------------
+----------+-----------
123| 456
- 123| 4567890123456789
-4567890123456789| 123
-4567890123456789| 4567890123456789
-4567890123456789|-4567890123456789
+ 123| 2147483647
+2147483647| 123
+2147483647| 2147483647
+2147483647|-2147483648
(5 rows)
QUERY: SELECT '' AS five, q1 AS plus, -q1 AS minus FROM INT8_TBL;
five| plus| minus
-----+----------------+-----------------
+----+----------+-----------
| 123| -123
| 123| -123
- |4567890123456789|-4567890123456789
- |4567890123456789|-4567890123456789
- |4567890123456789|-4567890123456789
+ |2147483647|-2147483647
+ |2147483647|-2147483647
+ |2147483647|-2147483647
(5 rows)
QUERY: SELECT '' AS five, q1, q2, q1 + q2 AS plus FROM INT8_TBL;
five| q1| q2| plus
-----+----------------+-----------------+----------------
+----+----------+-----------+-----------
| 123| 456| 579
- | 123| 4567890123456789|4567890123456912
- |4567890123456789| 123|4567890123456912
- |4567890123456789| 4567890123456789|9135780246913578
- |4567890123456789|-4567890123456789| 0
+ | 123| 2147483647|-2147483526
+ |2147483647| 123|-2147483526
+ |2147483647| 2147483647| -2
+ |2147483647|-2147483648| -1
(5 rows)
QUERY: SELECT '' AS five, q1, q2, q1 - q2 AS minus FROM INT8_TBL;
five| q1| q2| minus
-----+----------------+-----------------+-----------------
+----+----------+-----------+-----------
| 123| 456| -333
- | 123| 4567890123456789|-4567890123456666
- |4567890123456789| 123| 4567890123456666
- |4567890123456789| 4567890123456789| 0
- |4567890123456789|-4567890123456789| 9135780246913578
+ | 123| 2147483647|-2147483524
+ |2147483647| 123| 2147483524
+ |2147483647| 2147483647| 0
+ |2147483647|-2147483648| -1
(5 rows)
QUERY: SELECT '' AS three, q1, q2, q1 * q2 AS multiply FROM INT8_TBL
WHERE q1 < 1000 or (q2 > 0 and q2 < 1000);
three| q1| q2| multiply
------+----------------+----------------+------------------
+-----+----------+----------+----------
| 123| 456| 56088
- | 123|4567890123456789|561850485185185047
- |4567890123456789| 123|561850485185185047
+ | 123|2147483647|2147483525
+ |2147483647| 123|2147483525
(3 rows)
QUERY: SELECT '' AS five, q1, q2, q1 / q2 AS divide FROM INT8_TBL;
five| q1| q2| divide
-----+----------------+-----------------+--------------
+----+----------+-----------+--------
| 123| 456| 0
- | 123| 4567890123456789| 0
- |4567890123456789| 123|37137318076884
- |4567890123456789| 4567890123456789| 1
- |4567890123456789|-4567890123456789| -1
+ | 123| 2147483647| 0
+ |2147483647| 123|17459216
+ |2147483647| 2147483647| 1
+ |2147483647|-2147483648| 0
(5 rows)
QUERY: SELECT '' AS five, q1, float8(q1) FROM INT8_TBL;
five| q1|float8
-----+----------------+--------------------
+----+----------+----------
| 123|123
| 123|123
- |4567890123456789|4.56789012345679e+15
- |4567890123456789|4.56789012345679e+15
- |4567890123456789|4.56789012345679e+15
+ |2147483647|2147483647
+ |2147483647|2147483647
+ |2147483647|2147483647
(5 rows)
QUERY: SELECT '' AS five, q2, float8(q2) FROM INT8_TBL;
five| q2|float8
-----+-----------------+---------------------
+----+-----------+-----------
| 456|456
- | 4567890123456789|4.56789012345679e+15
+ | 2147483647| 2147483647
| 123|123
- | 4567890123456789|4.56789012345679e+15
- |-4567890123456789|-4.56789012345679e+15
+ | 2147483647| 2147483647
+ |-2147483648|-2147483648
(5 rows)
QUERY: SELECT '' AS five, q1, int8(float8(q1)) AS "two coercions" FROM INT8_TBL;
five| q1| two coercions
-----+----------------+----------------
+----+----------+-------------
| 123| 123
| 123| 123
- |4567890123456789|4567890123456789
- |4567890123456789|4567890123456789
- |4567890123456789|4567890123456789
+ |2147483647| 2147483647
+ |2147483647| 2147483647
+ |2147483647| 2147483647
(5 rows)
QUERY: SELECT '' AS five, 2 * q1 AS "twice int4" FROM INT8_TBL;
five| twice int4
-----+----------------
+----+----------
| 246
| 246
- |9135780246913578
- |9135780246913578
- |9135780246913578
+ | -2
+ | -2
+ | -2
(5 rows)
QUERY: SELECT '' AS five, q1 * 2 AS "twice int4" FROM INT8_TBL;
five| twice int4
-----+----------------
+----+----------
| 246
| 246
- |9135780246913578
- |9135780246913578
- |9135780246913578
+ | -2
+ | -2
+ | -2
(5 rows)
====== float8 ======
--- expected/float8.out Sun Aug 23 11:09:31 1998
+++ results/float8.out Tue Sep 1 23:40:11 1998
@@ -176,7 +176,7 @@
----+--------------------+--------------------
|0 |0
|1004.3 |10.014312837827
- |-34.84 |-3.26607421344208
+ |-34.84 |3.26607421344208
|1.2345678901234e+200|4.97933859234765e+66
|1.2345678901234e-200|2.3112042409018e-67
(5 rows)
@@ -197,7 +197,7 @@
QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
ERROR: Bad float8 input format -- overflow
QUERY: SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
-ERROR: pow() result is out of range
+ERROR: Bad float8 input format -- overflow
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 = '0.0' ;
ERROR: can't take log of zero
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 < '0.0' ;
====== geometry ======
--- expected/geometry.out Sun Aug 23 11:09:34 1998
+++ results/geometry.out Tue Sep 1 23:40:14 1998
@@ -99,7 +99,7 @@
|(5.1,34.5)|[(1,2),(3,4)] |(3,4)
|(-5,-12) |[(1,2),(3,4)] |(1,2)
|(10,10) |[(1,2),(3,4)] |(3,4)
- |(0,0) |[(0,0),(6,6)] |(-0,0)
+ |(0,0) |[(0,0),(6,6)] |(0,0)
|(-10,0) |[(0,0),(6,6)] |(0,0)
|(-3,4) |[(0,0),(6,6)] |(0.5,0.5)
|(5.1,34.5)|[(0,0),(6,6)] |(6,6)
@@ -112,7 +112,7 @@
|(-5,-12) |[(10,-10),(-3,-4)] |(-1.60487804878049,-4.64390243902439)
|(10,10) |[(10,-10),(-3,-4)] |(2.39024390243902,-6.48780487804878)
|(0,0) |[(-1000000,200),(300000,-40)]|(0.0028402365895872,15.384614860264)
- |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140473)
+ |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140472)
|(-3,4) |[(-1000000,200),(300000,-40)]|(-2.99789812267519,15.3851688427303)
|(5.1,34.5)|[(-1000000,200),(300000,-40)]|(5.09647083221496,15.3836744976925)
|(-5,-12) |[(-1000000,200),(300000,-40)]|(-4.99494420845634,15.3855375281616)
@@ -129,11 +129,11 @@
six|box
---+--------------------------------------------------------------------------
|(2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964)
- |(71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548)
- |(4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738)
- |(3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559643)
+ |(71.7106781186547,72.7106781186547),(-69.7106781186547,-68.7106781186547)
+ |(4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932737)
+ |(3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559642)
|(107.071067811865,207.071067811865),(92.9289321881345,192.928932188135)
- |(170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548)
+ |(170.710678118655,70.7106781186547),(29.2893218813453,-70.7106781186547)
(6 rows)
QUERY: SELECT '' AS twentyfour, b.f1 + p.f1 AS translation
@@ -204,11 +204,11 @@
|(0,0),(0,0)
|(0,0),(0,0)
|(0,0),(0,0)
- |(-0,0),(-20,-20)
+ |(0,0),(-20,-20)
|(-10,-10),(-30,-30)
|(-25,-25),(-25,-35)
|(-30,-30),(-30,-30)
- |(-0,2),(-14,0)
+ |(0,2),(-14,0)
|(-7,3),(-21,1)
|(-17.5,2.5),(-21.5,-0.5)
|(-21,3),(-21,3)
@@ -216,7 +216,7 @@
|(-29.4,118.8),(-88.2,39.6)
|(-73.5,104.1),(-108,99)
|(-88.2,118.8),(-88.2,118.8)
- |(14,-0),(0,-34)
+ |(14,0),(0,-34)
|(21,-17),(7,-51)
|(29.5,-42.5),(17.5,-47.5)
|(21,-51),(21,-51)
@@ -231,11 +231,11 @@
WHERE (p.f1 <-> '(0,0)'::point) >= 1;
twenty|rotation
------+---------------------------------------------------------------------------------
- |(0,-0),(-0.2,-0.2)
+ |(0,0),(-0.2,-0.2)
|(-0.1,-0.1),(-0.3,-0.3)
|(-0.25,-0.25),(-0.25,-0.35)
|(-0.3,-0.3),(-0.3,-0.3)
- |(0.08,-0),(0,-0.56)
+ |(0.08,0),(0,-0.56)
|(0.12,-0.28),(0.04,-0.84)
|(0.26,-0.7),(0.1,-0.82)
|(0.12,-0.84),(0.12,-0.84)
@@ -243,7 +243,7 @@
|(0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825)
|(0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521)
|(0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825)
- |(-0,0.0828402366863905),(-0.201183431952663,0)
+ |(0,0.0828402366863905),(-0.201183431952663,0)
|(-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953)
|(-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201)
|(-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586)
@@ -409,25 +409,25 @@
QUERY: SELECT '' AS six, polygon(f1)
FROM CIRCLE_TBL;
six|polygon
----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
|((-3,0),(-2.59807621135332,1.5),(-1.5,2.59807621135332),(-1.83690953073357e-16,3),(1.5,2.59807621135332),(2.59807621135332,1.5),(3,3.67381906146713e-16),(2.59807621135332,-1.5),(1.5,-2.59807621135332),(5.5107285922007e-16,-3),(-1.5,-2.59807621135332),(-2.59807621135332,-1.5))
-
|((-99,2),(-85.6025403784439,52),(-49,88.6025403784439),(0.999999999999994,102),(51,88.6025403784439),(87.6025403784439,52),(101,2.00000000000001),(87.6025403784439,-48),(51,-84.6025403784438),(1.00000000000002,-98),(-49,-84.6025403784439),(-85.6025403784438,-48))
-
|((-4,3),(-3.33012701892219,5.5),(-1.5,7.33012701892219),(1,8),(3.5,7.33012701892219),(5.33012701892219,5.5),(6,3),(5.33012701892219,0.500000000000001),(3.5,-1.33012701892219),(1,-2),(-1.5,-1.33012701892219),(-3.33012701892219,0.499999999999998))
-
|((-2,2),(-1.59807621135332,3.5),(-0.5,4.59807621135332),(1,5),(2.5,4.59807621135332),(3.59807621135332,3.5),(4,2),(3.59807621135332,0.500000000000001),(2.5,-0.598076211353315),(1,-1),(-0.5,-0.598076211353316),(-1.59807621135332,0.499999999999999))
-
|((90,200),(91.3397459621556,205),(95,208.660254037844),(100,210),(105,208.660254037844),(108.660254037844,205),(110,200),(108.660254037844,195),(105,191.339745962156),(100,190),(95,191.339745962156),(91.3397459621556,195))
-
|((0,0),(13.3974596215561,50),(50,86.6025403784439),(100,100),(150,86.6025403784439),(186.602540378444,50),(200,1.22460635382238e-14),(186.602540378444,-50),(150,-86.6025403784438),(100,-100),(50,-86.6025403784439),(13.3974596215562,-50))
+---+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
|((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.59807621135842),(1.53104195987908e-11,3),(1.50000000001768,2.59807621134311),(2.59807621136607,1.4999999999779),(3,-3.06208391975815e-11),(2.59807621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(-4.59312587963723e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807621138139,-1.49999999995138))
+
|((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.602540378614),(1.00000000051035,102),(51.0000000005893,88.6025403781036),(87.6025403788692,51.9999999992634),(101,1.99999999897931),(87.6025403778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999999998468958,-98),(-49.0000000014732,-84.6025403775933),(-85.6025403793795,-47.9999999983794))
+
|((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5.33012701894346,5.49999999996317),(6,2.99999999994897),(5.33012701889242,0.499999999948436),(3.49999999994107,-1.33012701895622),(0.999999999923448,-2),(-1.50000000007366,-1.33012701887966),(-3.33012701896897,0.500000000081029))
+
|((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.59807621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311),(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133545,0.499999999969062),(2.49999999996464,-0.59807621137373),(0.999999999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.59807621138139,0.500000000048617))
+
|((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.660254037861),(100.000000000051,210),(105.000000000059,208.66025403781),(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254037785,194.999999999897),(104.999999999882,191.339745962088),(99.9999999998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,195.000000000162))
+
|((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186.602540378869,49.9999999992634),(200,-1.02069463991938e-09),(186.602540377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.999999998469,-100),(49.9999999985268,-86.6025403775933),(13.3974596206205,-49.9999999983794))
(6 rows)
QUERY: SELECT '' AS six, polygon(8, f1)
FROM CIRCLE_TBL;
six|polygon
----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
|((-3,0),(-2.12132034355964,2.12132034355964),(-1.83690953073357e-16,3),(2.12132034355964,2.12132034355964),(3,3.67381906146713e-16),(2.12132034355964,-2.12132034355964),(5.5107285922007e-16,-3),(-2.12132034355964,-2.12132034355964))
-
|((-99,2),(-69.7106781186548,72.7106781186548),(0.999999999999994,102),(71.7106781186547,72.7106781186548),(101,2.00000000000001),(71.7106781186548,-68.7106781186547),(1.00000000000002,-98),(-69.7106781186547,-68.7106781186548))
-
|((-4,3),(-2.53553390593274,6.53553390593274),(1,8),(4.53553390593274,6.53553390593274),(6,3),(4.53553390593274,-0.535533905932737),(1,-2),(-2.53553390593274,-0.535533905932738))
-
|((-2,2),(-1.12132034355964,4.12132034355964),(1,5),(3.12132034355964,4.12132034355964),(4,2),(3.12132034355964,-0.121320343559642),(1,-1),(-1.12132034355964,-0.121320343559643))
-
|((90,200),(92.9289321881345,207.071067811865),(100,210),(107.071067811865,207.071067811865),(110,200),(107.071067811865,192.928932188135),(100,190),(92.9289321881345,192.928932188135))
-
|((0,0),(29.2893218813452,70.7106781186548),(100,100),(170.710678118655,70.7106781186548),(200,1.22460635382238e-14),(170.710678118655,-70.7106781186547),(100,-100),(29.2893218813453,-70.7106781186548))
+---+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
|((-3,0),(-2.12132034355423,2.12132034356506),(1.53104195987908e-11,3),(2.12132034357588,2.1213203435434),(3,-3.06208391975815e-11),(2.12132034353258,-2.12132034358671),(-4.59312587963723e-11,-3),(-2.12132034359753,-2.12132034352175))
+
|((-99,2),(-69.7106781184743,72.7106781188352),(1.00000000051035,102),(71.7106781191961,72.7106781181134),(101,1.99999999897931),(71.7106781177526,-68.7106781195569),(0.999999998468958,-98),(-69.7106781199178,-68.7106781173917))
+
|((-4,3),(-2.53553390592372,6.53553390594176),(1.00000000002552,8),(4.5355339059598,6.53553390590567),(6,2.99999999994897),(4.53553390588763,-0.535533905977846),(0.999999999923448,-2),(-2.53553390599589,-0.535533905869586))
+
|((-2,2),(-1.12132034355423,4.12132034356506),(1.00000000001531,5),(3.12132034357588,4.1213203435434),(4,1.99999999996938),(3.12132034353258,-0.121320343586708),(0.999999999954069,-1),(-1.12132034359753,-0.121320343521751))
+
|((90,200),(92.9289321881526,207.071067811884),(100.000000000051,210),(107.07106781192,207.071067811811),(110,199.999999999898),(107.071067811775,192.928932188044),(99.9999999998469,190),(92.9289321880082,192.928932188261))
+
|((0,0),(29.2893218815257,70.7106781188352),(100.00000000051,100),(170.710678119196,70.7106781181134),(200,-1.02069463991938e-09),(170.710678117753,-70.7106781195569),(99.999999998469,-100),(29.2893218800822,-70.7106781173917))
(6 rows)
QUERY: SELECT '' AS six, circle(f1, 50.0)
@@ -466,11 +466,11 @@
WHERE (p1.f1 <-> c1.f1) > 0
ORDER BY distance, circle, point using <<;
twentyfour|circle |point | distance
-----------+--------------+----------+-----------------
- |<(100,0),100> |(5.1,34.5)|0.976531926977964
+----------+--------------+----------+----------------
+ |<(100,0),100> |(5.1,34.5)|0.97653192697797
|<(1,2),3> |(-3,4) | 1.47213595499958
|<(0,0),3> |(-3,4) | 2
- |<(100,0),100> |(-3,4) | 3.07764064044151
+ |<(100,0),100> |(-3,4) |3.07764064044152
|<(100,0),100> |(-5,-12) | 5.68348972285122
|<(1,3),5> |(-10,0) | 6.40175425099138
|<(1,3),5> |(10,10) | 6.40175425099138
@@ -482,7 +482,7 @@
|<(0,0),3> |(10,10) | 11.142135623731
|<(1,3),5> |(-5,-12) | 11.1554944214035
|<(1,2),3> |(-5,-12) | 12.2315462117278
- |<(1,3),5> |(5.1,34.5)| 26.7657047773224
+ |<(1,3),5> |(5.1,34.5)|26.7657047773223
|<(1,2),3> |(5.1,34.5)| 29.757594539282
|<(0,0),3> |(5.1,34.5)| 31.8749193547455
|<(100,200),10>|(5.1,34.5)| 180.778038568384
====== tinterval ======
--- expected/tinterval.out Sun Aug 23 11:09:49 1998
+++ results/tinterval.out Tue Sep 1 23:40:17 1998
@@ -110,20 +110,20 @@
ORDER BY interval1, interval2;
fourteen|interval1 |interval2
--------+---------------------------------------------------------------+---------------------------------------------------------------
- |["-infinity" "infinity"] |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14
03:14:211973 PST"]
- |["-infinity" "infinity"] |["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04
23:59:121983 PDT"]
|["-infinity" "infinity"] |["epoch" "Mon May 01 00:30:30 1995 PDT"]
+ |["-infinity" "infinity"] |["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04
23:59:121983 PDT"]
|["-infinity" "infinity"] |["Thu Feb 15 12:15:03 1990 PST" "current"]
- |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14 03:14:21 1973 PST"]|["-infinity" "infinity"]
- |["epoch" "Mon May 01 00:30:30 1995 PDT"] |["-infinity" "infinity"]
- |["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04 23:59:12 1983 PDT"]|["-infinity" "infinity"]
+ |["-infinity" "infinity"] |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14
03:14:211973 PST"]
|["Thu Feb 15 12:15:03 1990 PST" "current"] |["-infinity" "infinity"]
+ |["epoch" "Mon May 01 00:30:30 1995 PDT"] |["Thu Feb 15 12:15:03 1990 PST" "current"]
+ |["epoch" "Mon May 01 00:30:30 1995 PDT"] |["-infinity" "infinity"]
+ |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14 03:14:21 1973 PST"]|["-infinity" "infinity"]
|["epoch" "Mon May 01 00:30:30 1995 PDT"] |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14
03:14:211973 PST"]
+ |["Thu Feb 15 12:15:03 1990 PST" "current"] |["epoch" "Mon May 01 00:30:30 1995 PDT"]
|["Sat May 10 23:59:12 1947 PST" "Sun Jan 14 03:14:21 1973 PST"]|["epoch" "Mon May 01 00:30:30 1995 PDT"]
|["epoch" "Mon May 01 00:30:30 1995 PDT"] |["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04
23:59:121983 PDT"]
- |["epoch" "Mon May 01 00:30:30 1995 PDT"] |["Thu Feb 15 12:15:03 1990 PST" "current"]
|["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04 23:59:12 1983 PDT"]|["epoch" "Mon May 01 00:30:30 1995 PDT"]
- |["Thu Feb 15 12:15:03 1990 PST" "current"] |["epoch" "Mon May 01 00:30:30 1995 PDT"]
+ |["Sun Sep 04 23:59:12 1983 PDT" "Tue Oct 04 23:59:12 1983 PDT"]|["-infinity" "infinity"]
(14 rows)
QUERY: SELECT '' AS five, t1.f1
====== select_having ======
--- expected/select_having.out Sat Aug 29 00:10:03 1998
+++ results/select_having.out Tue Sep 1 23:41:51 1998
@@ -11,27 +11,6 @@
QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
QUERY: SELECT max(a) FROM test_having
GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;
-max
----
- 5
- 9
-(2 rows)
-
-QUERY: SELECT lower(c), count(c) FROM test_having
- GROUP BY lower(c) HAVING count(*) > 2 OR min(a) = max(a);
-lower |count
---------+-----
-bbbb | 3
-cccc | 4
-xxxx | 1
-(3 rows)
-
-QUERY: SELECT c, max(a) FROM test_having
- GROUP BY c HAVING count(*) > 2 OR min(a) = max(a);
-c |max
---------+---
-XXXX | 0
-bbbb | 5
-(2 rows)
-
-QUERY: DROP TABLE test_having;
+pqReadData() -- backend closed the channel unexpectedly.
+ This probably means the backend terminated abnormally before or while processing the request.
+We have lost the connection to the backend, so further processing is impossible. Terminating.
====== misc ======
--- expected/misc.out Tue Sep 1 23:40:05 1998
+++ results/misc.out Tue Sep 1 23:42:04 1998
@@ -507,11 +507,12 @@
subselect_tbl
tenk1
tenk2
+test_having
text_tbl
timespan_tbl
tinterval_tbl
toyemp
varchar_tbl
xacttest
-(71 rows)
+(72 rows)
====== run_ruletest ======
--- expected/run_ruletest.out Sun Aug 23 11:09:42 1998
+++ results/run_ruletest.out Tue Sep 1 23:42:25 1998
@@ -254,12 +254,12 @@
QUERY: delete from rtest_emp where ename = 'gates';
QUERY: select * from rtest_emplog;
ename |who |action |newsal |oldsal
---------------------+-----+----------+----------+----------
-wiech |pgsql|hired |$5,000.00 |$0.00
-gates |pgsql|hired |$80,000.00|$0.00
-wieck |pgsql|honored |$6,000.00 |$5,000.00
-wieck |pgsql|honored |$7,000.00 |$6,000.00
-gates |pgsql|fired |$0.00 |$80,000.00
+--------------------+--------+----------+----------+----------
+wiech |postgres|hired |$5,000.00 |$0.00
+gates |postgres|hired |$80,000.00|$0.00
+wieck |postgres|honored |$6,000.00 |$5,000.00
+wieck |postgres|honored |$7,000.00 |$6,000.00
+gates |postgres|fired |$0.00 |$80,000.00
(5 rows)
QUERY: insert into rtest_empmass values ('meyer', '4000.00');
@@ -268,53 +268,53 @@
QUERY: insert into rtest_emp select * from rtest_empmass;
QUERY: select * from rtest_emplog;
ename |who |action |newsal |oldsal
---------------------+-----+----------+----------+----------
-wiech |pgsql|hired |$5,000.00 |$0.00
-gates |pgsql|hired |$80,000.00|$0.00
-wieck |pgsql|honored |$6,000.00 |$5,000.00
-wieck |pgsql|honored |$7,000.00 |$6,000.00
-gates |pgsql|fired |$0.00 |$80,000.00
-meyer |pgsql|hired |$4,000.00 |$0.00
-maier |pgsql|hired |$5,000.00 |$0.00
-mayr |pgsql|hired |$6,000.00 |$0.00
+--------------------+--------+----------+----------+----------
+wiech |postgres|hired |$5,000.00 |$0.00
+gates |postgres|hired |$80,000.00|$0.00
+wieck |postgres|honored |$6,000.00 |$5,000.00
+wieck |postgres|honored |$7,000.00 |$6,000.00
+gates |postgres|fired |$0.00 |$80,000.00
+meyer |postgres|hired |$4,000.00 |$0.00
+maier |postgres|hired |$5,000.00 |$0.00
+mayr |postgres|hired |$6,000.00 |$0.00
(8 rows)
QUERY: update rtest_empmass set salary = salary + '1000.00';
QUERY: update rtest_emp set salary = rtest_empmass.salary where ename = rtest_empmass.ename;
QUERY: select * from rtest_emplog;
ename |who |action |newsal |oldsal
---------------------+-----+----------+----------+----------
-wiech |pgsql|hired |$5,000.00 |$0.00
-gates |pgsql|hired |$80,000.00|$0.00
-wieck |pgsql|honored |$6,000.00 |$5,000.00
-wieck |pgsql|honored |$7,000.00 |$6,000.00
-gates |pgsql|fired |$0.00 |$80,000.00
-meyer |pgsql|hired |$4,000.00 |$0.00
-maier |pgsql|hired |$5,000.00 |$0.00
-mayr |pgsql|hired |$6,000.00 |$0.00
-maier |pgsql|honored |$6,000.00 |$5,000.00
-mayr |pgsql|honored |$7,000.00 |$6,000.00
-meyer |pgsql|honored |$5,000.00 |$4,000.00
+--------------------+--------+----------+----------+----------
+wiech |postgres|hired |$5,000.00 |$0.00
+gates |postgres|hired |$80,000.00|$0.00
+wieck |postgres|honored |$6,000.00 |$5,000.00
+wieck |postgres|honored |$7,000.00 |$6,000.00
+gates |postgres|fired |$0.00 |$80,000.00
+meyer |postgres|hired |$4,000.00 |$0.00
+maier |postgres|hired |$5,000.00 |$0.00
+mayr |postgres|hired |$6,000.00 |$0.00
+maier |postgres|honored |$6,000.00 |$5,000.00
+mayr |postgres|honored |$7,000.00 |$6,000.00
+meyer |postgres|honored |$5,000.00 |$4,000.00
(11 rows)
QUERY: delete from rtest_emp where ename = rtest_empmass.ename;
QUERY: select * from rtest_emplog;
ename |who |action |newsal |oldsal
---------------------+-----+----------+----------+----------
-wiech |pgsql|hired |$5,000.00 |$0.00
-gates |pgsql|hired |$80,000.00|$0.00
-wieck |pgsql|honored |$6,000.00 |$5,000.00
-wieck |pgsql|honored |$7,000.00 |$6,000.00
-gates |pgsql|fired |$0.00 |$80,000.00
-meyer |pgsql|hired |$4,000.00 |$0.00
-maier |pgsql|hired |$5,000.00 |$0.00
-mayr |pgsql|hired |$6,000.00 |$0.00
-maier |pgsql|honored |$6,000.00 |$5,000.00
-mayr |pgsql|honored |$7,000.00 |$6,000.00
-meyer |pgsql|honored |$5,000.00 |$4,000.00
-maier |pgsql|fired |$0.00 |$6,000.00
-mayr |pgsql|fired |$0.00 |$7,000.00
-meyer |pgsql|fired |$0.00 |$5,000.00
+--------------------+--------+----------+----------+----------
+wiech |postgres|hired |$5,000.00 |$0.00
+gates |postgres|hired |$80,000.00|$0.00
+wieck |postgres|honored |$6,000.00 |$5,000.00
+wieck |postgres|honored |$7,000.00 |$6,000.00
+gates |postgres|fired |$0.00 |$80,000.00
+meyer |postgres|hired |$4,000.00 |$0.00
+maier |postgres|hired |$5,000.00 |$0.00
+mayr |postgres|hired |$6,000.00 |$0.00
+maier |postgres|honored |$6,000.00 |$5,000.00
+mayr |postgres|honored |$7,000.00 |$6,000.00
+meyer |postgres|honored |$5,000.00 |$4,000.00
+maier |postgres|fired |$0.00 |$6,000.00
+mayr |postgres|fired |$0.00 |$7,000.00
+meyer |postgres|fired |$0.00 |$5,000.00
(14 rows)
QUERY: insert into rtest_t4 values (1, 'Record should go to rtest_t4');
> > Uh, no, Linux/i686 is showing trouble too, but not in the initdb
> > stage. The Sparc platforms will be more sensitive to byte alignment
> > problems, especially within C structures, so this may be
> > illustrating a cross-platform problem more clearly.
> > There is a repeatable indexing and (perhaps) caching problem I see
> > in the regression tests. Annoyingly, the problems get slightly worse
> > at the moment when compiling with -O0.
> OK, here is my regression output. Do you see anything strange in
> there?
Well, yes, just not as strange as my tests :) You don't have int8
enabled, and if your compiler and libc allow it I'd like to get that
going. But that isn't a problem.
You have a core dump from the "having" test. Is that a known problem
with someone working on a solution? The test worked on my ~month-old
development tree (I could probably figure out the vintage of that tree
to more precision if it would be helpful), so something has happened in
the meantime.
I suspect that (possibly) more than one thing is going on, since there
were some changes directly related to removing the oddball OID types as
well as perhaps cleanup changes made while traversing the code.
Something may have crept in there.
If these tests are the only ones showing problems on your machine, then
consider yourself lucky. I've got several more failures, including the
one where I can't create indices on a table until after terminating and
restarting the session. The Sparc contingent sees more problems than I,
but they are on a Risc machine so will see alignment problems if they
are present.
- Tom
> ====== int8 ======
> --- expected/int8.out Sun Aug 23 11:09:38 1998
> +++ results/int8.out Tue Sep 1 23:40:10 1998
> @@ -6,110 +6,110 @@
> QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
> QUERY: SELECT * FROM INT8_TBL;
> q1| q2
> -----------------+-----------------
> +----------+-----------
> 123| 456
> - 123| 4567890123456789
> -4567890123456789| 123
> -4567890123456789| 4567890123456789
> -4567890123456789|-4567890123456789
> + 123| 2147483647
> +2147483647| 123
> +2147483647| 2147483647
> +2147483647|-2147483648
> (5 rows)
> ====== select_having ======
> --- expected/select_having.out Sat Aug 29 00:10:03 1998
> +++ results/select_having.out Tue Sep 1 23:41:51 1998
> @@ -11,27 +11,6 @@
> QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
> QUERY: SELECT max(a) FROM test_having
> GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;
<snip>
> -QUERY: DROP TABLE test_having;
> +pqReadData() -- backend closed the channel unexpectedly.
> + This probably means the backend terminated abnormally before or while processing the request.
> +We have lost the connection to the backend, so further processing is impossible. Terminating.
OK, this test did not fail on my development tree from a month ago. What
changed? I'm seeing it fail here also.
- Tom
> > Can we try a simple -O rather than just -O2 and -O0. Could this be > > some type of optimizer bug in gcc2/Solaris? > > Everything is pointing to indexing.c, from both the initdb failure and > > the create function failure. But I can't see anything wrong in there, > > and other platforms seem to be OK. > > Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage. > The Sparc platforms will be more sensitive to byte alignment problems, > especially within C structures, so this may be illustrating a > cross-platform problem more clearly. > > There is a repeatable indexing and (perhaps) caching problem I see in > the regression tests. Annoyingly, the problems get slightly worse at the > moment when compiling with -O0. Can you see if compiling indexing.c with different optmization levels change the output? If so, would someone else also look in indexing.c for somethings stupid I did. I can't see it, but EVERYTHING is pointing to that file. > > There is a fundamental problem lurking somewhere, and there may not be > much point in going beta unless you think that more testers will help to > track down the problem. Not sure how to find the problem. Without being able to debug it here, I am left staring at the code over and over again. -- 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)
> > > Uh, no, Linux/i686 is showing trouble too, but not in the initdb
> > > stage. The Sparc platforms will be more sensitive to byte alignment
> > > problems, especially within C structures, so this may be
> > > illustrating a cross-platform problem more clearly.
> > > There is a repeatable indexing and (perhaps) caching problem I see
> > > in the regression tests. Annoyingly, the problems get slightly worse
> > > at the moment when compiling with -O0.
> > OK, here is my regression output. Do you see anything strange in
> > there?
>
> Well, yes, just not as strange as my tests :) You don't have int8
> enabled, and if your compiler and libc allow it I'd like to get that
> going. But that isn't a problem.
>
> You have a core dump from the "having" test. Is that a known problem
> with someone working on a solution? The test worked on my ~month-old
> development tree (I could probably figure out the vintage of that tree
> to more precision if it would be helpful), so something has happened in
> the meantime.
>
> I suspect that (possibly) more than one thing is going on, since there
> were some changes directly related to removing the oddball OID types as
> well as perhaps cleanup changes made while traversing the code.
> Something may have crept in there.
>
> If these tests are the only ones showing problems on your machine, then
> consider yourself lucky. I've got several more failures, including the
> one where I can't create indices on a table until after terminating and
> restarting the session. The Sparc contingent sees more problems than I,
> but they are on a Risc machine so will see alignment problems if they
> are present.
Yes, very strange.
>
> - Tom
>
> > ====== int8 ======
> > --- expected/int8.out Sun Aug 23 11:09:38 1998
> > +++ results/int8.out Tue Sep 1 23:40:10 1998
> > @@ -6,110 +6,110 @@
> > QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
> > QUERY: SELECT * FROM INT8_TBL;
> > q1| q2
> > -----------------+-----------------
> > +----------+-----------
> > 123| 456
> > - 123| 4567890123456789
> > -4567890123456789| 123
> > -4567890123456789| 4567890123456789
> > -4567890123456789|-4567890123456789
> > + 123| 2147483647
> > +2147483647| 123
> > +2147483647| 2147483647
> > +2147483647|-2147483648
> > (5 rows)
> > ====== select_having ======
> > --- expected/select_having.out Sat Aug 29 00:10:03 1998
> > +++ results/select_having.out Tue Sep 1 23:41:51 1998
> > @@ -11,27 +11,6 @@
> > QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
> > QUERY: SELECT max(a) FROM test_having
> > GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;
> <snip>
> > -QUERY: DROP TABLE test_having;
> > +pqReadData() -- backend closed the channel unexpectedly.
> > + This probably means the backend terminated abnormally before or while processing the request.
> > +We have lost the connection to the backend, so further processing is impossible. Terminating.
>
> OK, this test did not fail on my development tree from a month ago. What
> changed? I'm seeing it fail here also.
I believe David Hartwig has claimed this problem, and knows the cause.
He posted something recently.
--
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)
Bruce Momjian wrote:
>
> Not sure how to find the problem. Without being able to debug it here,
> I am left staring at the code over and over again.
That sounds like *so* much fun ;-)
OK, I've been ignoring the problem until now, and of course may not be
of any help even if I were trying to help. I'm also not quite up on the
history and sequence of events which led to our current state, and I'm
not sure we have a strong regression history yet to pin this down.
At the moment we have Bruce and the two sparc guys working on it, and
Bruce can't reproduce the problems on his machine and Keith's machine is
so dog-slow that he can't do much testing which involve full rebuilds.
Boy, it hasn't been long since that model Sparc was the best thing
going, eh?
Does anyone else have a machine (Linux x86, for example) which exhibits
problems with the current development tree, and who has an interest in
helping to track this down?
I hate to step away from docs, but could for a while if that would be
helpful. I've got a fairly fast machine and can try pinning down when
the problems started by doing full builds on fresh trees. Or since we've
been making steady incremental improvements to the tree, maybe we should
focus on a particular problem; my "can't create another index in the
current session" problem is probably related to whatever else is going
on with indices.
In general the problems persist across different "-O" compiler settings
and across different architectures and compilers, though with different
symptoms, so I would think that this is not a compiler bug per se.
- Tom
> Bruce Momjian wrote: > > > > Not sure how to find the problem. Without being able to debug it here, > > I am left staring at the code over and over again. > > That sounds like *so* much fun ;-) > > OK, I've been ignoring the problem until now, and of course may not be > of any help even if I were trying to help. I'm also not quite up on the > history and sequence of events which led to our current state, and I'm > not sure we have a strong regression history yet to pin this down. > > At the moment we have Bruce and the two sparc guys working on it, and > Bruce can't reproduce the problems on his machine and Keith's machine is > so dog-slow that he can't do much testing which involve full rebuilds. > Boy, it hasn't been long since that model Sparc was the best thing > going, eh? I was on Thomas A. Szybist machine for two hours, and even though I was telnet'ed across three Internet machines to get there, it made my PP200 look like it was sitting still. Amazing speed. It is a Sparc running Solaris. -- 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)
In message <199809021542.LAA02771@candle.pha.pa.us>, Bruce Momjian writes:
> > Bruce Momjian wrote:
> > >
> > > Not sure how to find the problem. Without being able to debug it here,
> > > I am left staring at the code over and over again.
> >
> > That sounds like *so* much fun ;-)
> >
> > OK, I've been ignoring the problem until now, and of course may not be
> > of any help even if I were trying to help. I'm also not quite up on the
> > history and sequence of events which led to our current state, and I'm
> > not sure we have a strong regression history yet to pin this down.
> >
> > At the moment we have Bruce and the two sparc guys working on it, and
> > Bruce can't reproduce the problems on his machine and Keith's machine is
> > so dog-slow that he can't do much testing which involve full rebuilds.
> > Boy, it hasn't been long since that model Sparc was the best thing
> > going, eh?
>
> I was on Thomas A. Szybist machine for two hours, and even though I was
^^^^^^^^^^^^^^^^^
It's really just Tom :)
> telnet'ed across three Internet machines to get there, it made my PP200
> look like it was sitting still. Amazing speed. It is a Sparc running
> Solaris.
>
> --
> 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)
I just grabbed grabbed gcc 2.8.1 from smc.vnet.com. I should have that
installed later today. Full rebuilds are not a problem for me. I did
just get a project bubbled to the top of my queue here that should take
about a day or two. I certainly can try patches and such, but I may
not have time plod through with gdb for a few days. (Not that I can
help much anyway.) I'm also going to be away for Labor day starting
Friday night EST. I'm returning on Tuesday night EST.
Tom Szybist
szybist@boxhill.com
Thomas G. Lockhart wrote: > > > Uh, no, Linux/i686 is showing trouble too, but not in the initdb > > > stage. The Sparc platforms will be more sensitive to byte alignment > > > problems, especially within C structures, so this may be > > > illustrating a cross-platform problem more clearly. > > > There is a repeatable indexing and (perhaps) caching problem I see > > > in the regression tests. Annoyingly, the problems get slightly worse > > > at the moment when compiling with -O0. > > OK, here is my regression output. Do you see anything strange in > > there? > > Well, yes, just not as strange as my tests :) You don't have int8 > enabled, and if your compiler and libc allow it I'd like to get that > going. But that isn't a problem. > > You have a core dump from the "having" test. Is that a known problem > with someone working on a solution? The test worked on my ~month-old > development tree (I could probably figure out the vintage of that tree > to more precision if it would be helpful), so something has happened in > the meantime. > I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch. The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do with having. It has to do with GROUPing by a function and the argument of the function not appearing elsewhere in the target list. Weird! In any case the latest patch will fix the regression. BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR memory exhaustion fix.
> I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by > a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch. > > The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first > patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do > with having. It has to do with GROUPing by a function and the argument of the function not appearing > elsewhere in the target list. Weird! In any case the latest patch will fix the regression. > > BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR > memory exhaustion fix. Yes, I am behind on the patch applications. Marc probably stopped while I did my mega-cleanup, and I have been scratching my head on the platform failures. Hopefully one of us will get it soon. -- 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)
Bruce Momjian wrote: > > I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by > > a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch. > > > > The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first > > patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do > > with having. It has to do with GROUPing by a function and the argument of the function not appearing > > elsewhere in the target list. Weird! In any case the latest patch will fix the regression. > > > > BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR > > memory exhaustion fix. > > Yes, I am behind on the patch applications. Marc probably stopped while > I did my mega-cleanup, and I have been scratching my head on the > platform failures. Hopefully one of us will get it soon. > bug. No rush, I can see you're synapses are all firing on this index bug. Just a reminder so it doesn't fall through the cracks. More important, am relieved (in advance) that you have found the problem in the index code. Can I assume there will be a snapshot I can get tomorrow from my business location to try out on my AIX box? I am anxious to know this is behind us. Appreciation :)
> > No rush, I can see you're synapses are all firing on this index bug. Just a reminder so it doesn't fall > through the cracks. Doing it now. > > More important, am relieved (in advance) that you have found the problem in the index code. > > Can I assume there will be a snapshot I can get tomorrow from my business location to try out on my AIX box? I > am anxious to know this is behind us. > > Appreciation :) Last I heard on Monday, Marc is making snapshots every day now, and through the beta period. Thanks to all the bug reports and tracebacks. They clearly pointed to the problem. I just couldn't see it until today. -- 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)