regression failure in CVS HEAD
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.
The platform is Linux 2.4, gcc 3.2. I've attached the regression.diffs
file.
Any ideas on what the cause might be?
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachments:
regression.diffstext/x-patch; charset=ANSI_X3.4-1968; name=regression.diffsDownload
*** ./expected/triggers.out Sat Nov 23 13:13:22 2002
--- ./results/triggers.out Fri Mar 7 15:48:41 2003
***************
*** 88,93 ****
--- 88,94 ----
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
DROP TABLE pkeys;
DROP TABLE fkeys;
+ ERROR: DeleteRelationTuple: cache lookup failed for relation 122479
DROP TABLE fkeys2;
-- -- I've disabled the funny_dup17 test because the new semantics
-- -- of AFTER ROW triggers, which get now fired at the end of a
======================================================================
*** ./expected/inherit.out Thu Mar 6 00:47:52 2003
--- ./results/inherit.out Fri Mar 7 15:48:41 2003
***************
*** 26,31 ****
--- 26,32 ----
INSERT INTO c(aa) VALUES('ccccccc');
INSERT INTO c(aa) VALUES('cccccccc');
INSERT INTO d(aa) VALUES('ddd');
+ ERROR: Relation 125442 does not exist
INSERT INTO d(aa) VALUES('dddd');
INSERT INTO d(aa) VALUES('ddddd');
INSERT INTO d(aa) VALUES('dddddd');
***************
*** 52,64 ****
c | cccccc
c | ccccccc
c | cccccccc
- d | ddd
d | dddd
d | ddddd
d | dddddd
d | ddddddd
d | dddddddd
! (24 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
--- 53,64 ----
c | cccccc
c | ccccccc
c | cccccccc
d | dddd
d | ddddd
d | dddddd
d | ddddddd
d | dddddddd
! (23 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
***************
*** 69,81 ****
b | bbbbbb |
b | bbbbbbb |
b | bbbbbbbb |
- d | ddd |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (12 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
--- 69,80 ----
b | bbbbbb |
b | bbbbbbb |
b | bbbbbbbb |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (11 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
***************
*** 86,109 ****
c | cccccc |
c | ccccccc |
c | cccccccc |
- d | ddd |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (12 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
- d | ddd | | |
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (6 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
--- 85,106 ----
c | cccccc |
c | ccccccc |
c | cccccccc |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (11 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (5 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
***************
*** 141,153 ****
SELECT relname, d.* FROM ONLY d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
- d | ddd | | |
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (6 rows)
UPDATE a SET aa='zzzz' WHERE aa='aaaa';
UPDATE ONLY a SET aa='zzzzz' WHERE aa='aaaaa';
--- 138,149 ----
SELECT relname, d.* FROM ONLY d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (5 rows)
UPDATE a SET aa='zzzz' WHERE aa='aaaa';
UPDATE ONLY a SET aa='zzzzz' WHERE aa='aaaaa';
***************
*** 175,187 ****
c | cccccc
c | ccccccc
c | cccccccc
- d | ddd
d | dddd
d | ddddd
d | dddddd
d | ddddddd
d | dddddddd
! (24 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
--- 171,182 ----
c | cccccc
c | ccccccc
c | cccccccc
d | dddd
d | ddddd
d | dddddd
d | ddddddd
d | dddddddd
! (23 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
***************
*** 192,204 ****
b | bbbbbb |
b | bbbbbbb |
b | bbbbbbbb |
- d | ddd |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (12 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
--- 187,198 ----
b | bbbbbb |
b | bbbbbbb |
b | bbbbbbbb |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (11 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
***************
*** 209,232 ****
c | cccccc |
c | ccccccc |
c | cccccccc |
- d | ddd |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (12 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
- d | ddd | | |
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (6 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
--- 203,224 ----
c | cccccc |
c | ccccccc |
c | cccccccc |
d | dddd |
d | ddddd |
d | dddddd |
d | ddddddd |
d | dddddddd |
! (11 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (5 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
***************
*** 264,276 ****
SELECT relname, d.* FROM ONLY d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
- d | ddd | | |
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (6 rows)
UPDATE b SET aa='new';
SELECT relname, a.* FROM a, pg_class where a.tableoid = pg_class.oid;
--- 256,267 ----
SELECT relname, d.* FROM ONLY d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
---------+----------+----+----+----
d | dddd | | |
d | ddddd | | |
d | dddddd | | |
d | ddddddd | | |
d | dddddddd | | |
! (5 rows)
UPDATE b SET aa='new';
SELECT relname, a.* FROM a, pg_class where a.tableoid = pg_class.oid;
***************
*** 299,306 ****
d | new
d | new
d | new
! d | new
! (24 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
--- 290,296 ----
d | new
d | new
d | new
! (23 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
***************
*** 316,323 ****
d | new |
d | new |
d | new |
! d | new |
! (12 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
--- 306,312 ----
d | new |
d | new |
d | new |
! (11 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
***************
*** 333,340 ****
d | new |
d | new |
d | new |
! d | new |
! (12 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
--- 322,328 ----
d | new |
d | new |
d | new |
! (11 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
***************
*** 344,351 ****
d | new | | |
d | new | | |
d | new | | |
! d | new | | |
! (6 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
--- 332,338 ----
d | new | | |
d | new | | |
d | new | | |
! (5 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
***************
*** 388,395 ****
d | new | | |
d | new | | |
d | new | | |
! d | new | | |
! (6 rows)
UPDATE a SET aa='new';
DELETE FROM ONLY c WHERE aa='new';
--- 375,381 ----
d | new | | |
d | new | | |
d | new | | |
! (5 rows)
UPDATE a SET aa='new';
DELETE FROM ONLY c WHERE aa='new';
***************
*** 413,420 ****
d | new
d | new
d | new
! d | new
! (18 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
--- 399,405 ----
d | new
d | new
d | new
! (17 rows)
SELECT relname, b.* FROM b, pg_class where b.tableoid = pg_class.oid;
relname | aa | bb
***************
*** 430,437 ****
d | new |
d | new |
d | new |
! d | new |
! (12 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
--- 415,421 ----
d | new |
d | new |
d | new |
! (11 rows)
SELECT relname, c.* FROM c, pg_class where c.tableoid = pg_class.oid;
relname | aa | cc
***************
*** 441,448 ****
d | new |
d | new |
d | new |
! d | new |
! (6 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
--- 425,431 ----
d | new |
d | new |
d | new |
! (5 rows)
SELECT relname, d.* FROM d, pg_class where d.tableoid = pg_class.oid;
relname | aa | bb | cc | dd
***************
*** 452,459 ****
d | new | | |
d | new | | |
d | new | | |
! d | new | | |
! (6 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
--- 435,441 ----
d | new | | |
d | new | | |
d | new | | |
! (5 rows)
SELECT relname, a.* FROM ONLY a, pg_class where a.tableoid = pg_class.oid;
relname | aa
***************
*** 490,497 ****
d | new | | |
d | new | | |
d | new | | |
! d | new | | |
! (6 rows)
DELETE FROM a;
SELECT relname, a.* FROM a, pg_class where a.tableoid = pg_class.oid;
--- 472,478 ----
d | new | | |
d | new | | |
d | new | | |
! (5 rows)
DELETE FROM a;
SELECT relname, a.* FROM a, pg_class where a.tableoid = pg_class.oid;
======================================================================
*** ./expected/vacuum.out Sat Jul 20 00:58:14 2002
--- ./results/vacuum.out Fri Mar 7 15:48:41 2003
***************
*** 30,35 ****
--- 30,36 ----
VACUUM FULL vactst;
UPDATE vactst SET i = i + 1;
+ ERROR: Relation 124108 does not exist
INSERT INTO vactst SELECT * FROM vactst;
INSERT INTO vactst SELECT * FROM vactst;
INSERT INTO vactst SELECT * FROM vactst;
======================================================================
*** ./expected/sanity_check.out Mon Aug 19 15:33:36 2002
--- ./results/sanity_check.out Fri Mar 7 15:48:48 2003
***************
*** 15,20 ****
--- 15,21 ----
bt_name_heap | t
bt_txt_heap | t
fast_emp4000 | t
+ fkeys | t
func_index_heap | t
hash_f8_heap | t
hash_i4_heap | t
***************
*** 62,68 ****
shighway | t
tenk1 | t
tenk2 | t
! (52 rows)
--
-- another sanity check: every system catalog that has OIDs should have
--- 63,69 ----
shighway | t
tenk1 | t
tenk2 | t
! (53 rows)
--
-- another sanity check: every system catalog that has OIDs should have
======================================================================
*** ./expected/misc.out Sat Feb 22 20:01:12 2003
--- ./results/misc.out Fri Mar 7 15:48:51 2003
***************
*** 598,603 ****
--- 598,604 ----
equipment_r
f_star
fast_emp4000
+ fkeys
float4_tbl
float8_tbl
func_index_heap
***************
*** 659,665 ****
toyemp
varchar_tbl
xacttest
! (95 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
--- 660,666 ----
toyemp
varchar_tbl
xacttest
! (96 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
======================================================================
Neil Conway <neilc@samurai.com> writes:
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.The platform is Linux 2.4, gcc 3.2. I've attached the regression.diffs
file.Any ideas on what the cause might be?
Hardware?
If it's a software bug, you'd generally expect it to happen each and
every time...
-Doug
Import Notes
Reply to msg id not found: NeilConwaysmessageof07Mar2003155301-0500
On Fri, 2003-03-07 at 17:05, Doug McNaught wrote:
Neil Conway <neilc@samurai.com> writes:
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.The platform is Linux 2.4, gcc 3.2. I've attached the regression.diffs
file.Any ideas on what the cause might be?
Hardware?
If it's a software bug, you'd generally expect it to happen each and
every time...
It could be an order dependency in a parallel group.
The sequential runs don't throw a periodic error do they?
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Neil Conway <neilc@samurai.com> writes:
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.
Yipes. I have not been running the parallel tests (my habit is to run
make installcheck, instead) but there is clearly something busted.
I got a bunch of failures similar to yours in my first attempt with
make check on HPUX --- see attached.
Any ideas on what the cause might be?
No. Can anyone offer data on when this started?
regards, tom lane
*** ./expected/constraints.out Sat Mar 8 00:16:33 2003
--- ./results/constraints.out Sat Mar 8 00:21:00 2003
***************
*** 11,31 ****
--
CREATE TABLE DEFAULT_TBL (i int DEFAULT 100,
x text DEFAULT 'vadim', f float8 DEFAULT 123.456);
INSERT INTO DEFAULT_TBL VALUES (1, 'thomas', 57.0613);
INSERT INTO DEFAULT_TBL VALUES (1, 'bruce');
INSERT INTO DEFAULT_TBL (i, f) VALUES (2, 987.654);
INSERT INTO DEFAULT_TBL (x) VALUES ('marc');
INSERT INTO DEFAULT_TBL VALUES (3, null, 1.0);
SELECT '' AS five, * FROM DEFAULT_TBL;
! five | i | x | f
! ------+-----+--------+---------
! | 1 | thomas | 57.0613
! | 1 | bruce | 123.456
! | 2 | vadim | 987.654
! | 100 | marc | 123.456
! | 3 | | 1
! (5 rows)
!
CREATE SEQUENCE DEFAULT_SEQ;
CREATE TABLE DEFAULTEXPR_TBL (i1 int DEFAULT 100 + (200-199) * 2,
i2 int DEFAULT nextval('default_seq'));
--- 11,29 ----
--
CREATE TABLE DEFAULT_TBL (i int DEFAULT 100,
x text DEFAULT 'vadim', f float8 DEFAULT 123.456);
+ ERROR: cache lookup of relation 119389 failed
INSERT INTO DEFAULT_TBL VALUES (1, 'thomas', 57.0613);
+ ERROR: Relation "default_tbl" does not exist
INSERT INTO DEFAULT_TBL VALUES (1, 'bruce');
+ ERROR: Relation "default_tbl" does not exist
INSERT INTO DEFAULT_TBL (i, f) VALUES (2, 987.654);
+ ERROR: Relation "default_tbl" does not exist
INSERT INTO DEFAULT_TBL (x) VALUES ('marc');
+ ERROR: Relation "default_tbl" does not exist
INSERT INTO DEFAULT_TBL VALUES (3, null, 1.0);
+ ERROR: Relation "default_tbl" does not exist
SELECT '' AS five, * FROM DEFAULT_TBL;
! ERROR: Relation "default_tbl" does not exist
CREATE SEQUENCE DEFAULT_SEQ;
CREATE TABLE DEFAULTEXPR_TBL (i1 int DEFAULT 100 + (200-199) * 2,
i2 int DEFAULT nextval('default_seq'));======================================================================
*** ./expected/misc.out Sat Mar 8 00:16:33 2003
--- ./results/misc.out Sat Mar 8 00:21:52 2003
***************
*** 590,596 ****
d_star
date_tbl
default_seq
- default_tbl
defaultexpr_tbl
dept
e_star
--- 590,595 ----
***************
*** 659,665 ****
toyemp
varchar_tbl
xacttest
! (95 rows) --SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
--- 658,664 ----
toyemp
varchar_tbl
xacttest
! (94 rows) --SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))) AS equip_name;
SELECT hobbies_by_name('basketball');
======================================================================
Yipes. I have not been running the parallel tests (my habit is to run
make installcheck, instead) but there is clearly something busted.
I got a bunch of failures similar to yours in my first attempt with
make check on HPUX --- see attached.Any ideas on what the cause might be?
No. Can anyone offer data on when this started?
I see passes on March 2nd, updated and see passes today.
Did 5 runs of make check on today source.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
I said:
Neil Conway <neilc@samurai.com> writes:
About 1 in every 5 runs of the (parallel) regression tests are failing
for me with CVS HEAD: the triggers, inherit, vacuum, sanity_check, and
misc tests fail. I can make the failures occur fairly consistently by
running "make check" over and over again until the problem crops up.
Yipes. I have not been running the parallel tests (my habit is to run
make installcheck, instead) but there is clearly something busted.
I've spent the morning trying to reproduce this, without success. After
a "make maintainer-clean", cvs update, full rebuild cycle, I cannot get
anything funny to happen in "make check" under HPUX, RH Linux 8.0, or
OS X.
I'm a bit hesitant to write it off as a build problem, because
(a) I can't see anything in the recent CVS logs that might cause such,
and (b) it's surprising that it'd bite both you and me. But at this
point I don't see what else to say.
Can you still reproduce the problem after a clean rebuild?
regards, tom lane
Tom Lane wrote:
I've spent the morning trying to reproduce this, without success. After
a "make maintainer-clean", cvs update, full rebuild cycle, I cannot get
anything funny to happen in "make check" under HPUX, RH Linux 8.0, or
OS X.I'm a bit hesitant to write it off as a build problem, because
(a) I can't see anything in the recent CVS logs that might cause such,
and (b) it's surprising that it'd bite both you and me. But at this
point I don't see what else to say.Can you still reproduce the problem after a clean rebuild?
FWIW, I just updated to cvs tip, did
make clean
./configure ...
make all
make install
make check (repeated 6 times)
The only failure I get is horology due to the
"--enable-integer-datetimes" issue (which I think there is a patch in
the queue for). This is on Red Hat 7.3.
Joe
On Sat, 2003-03-08 at 12:41, Tom Lane wrote:
Can you still reproduce the problem after a clean rebuild?
No -- I ran "cvs update", "make clean", followed by 10 runs of the
regression tests but I didn't get any similar failures.
I suppose we can just regard it as a build problem, then? Not sure what
the actual culprit was, though...
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
I suppose we can just regard it as a build problem, then? Not sure what
the actual culprit was, though...
I'm mystified too. But unless we see it again, I think we have to write
it off as a build error.
Do you use --enable-depend when configuring? I don't, so I know that
I take some risk of build errors when I do things wrong.
regards, tom lane
On Sat, 2003-03-08 at 21:29, Tom Lane wrote:
Do you use --enable-depend when configuring? I don't, so I know that
I take some risk of build errors when I do things wrong.
Yeah, I did -- which I why when I reported it initially I assumed that a
build problem wasn't the cause.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
On Sat, 2003-03-08 at 21:29, Tom Lane wrote:
Do you use --enable-depend when configuring? I don't, so I know that
I take some risk of build errors when I do things wrong.
Yeah, I did -- which I why when I reported it initially I assumed that a
build problem wasn't the cause.
Hm. One of the reasons I don't use --enable-depend is that I don't
trust it ;-) --- I prefer to do a make clean and rebuild after every
cvs update.
It's disturbing that we both saw similar failures, when there's no
obvious explanation for a build problem in the CVS logs. I have a
sneaking feeling that we haven't seen the last of this issue. But with
no ability to reproduce it, there's not much point in worrying now.
regards, tom lane