Re: [HACKERS] regression failure in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] regression failure in CVS HEAD
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 <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression failure in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] regression failure in CVS HEAD
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 <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression failure in CVS HEAD
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] regression failure in CVS HEAD
I said: > Neil Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] regression failure in CVS HEAD
> 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 <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] regression failure in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> 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');
==
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regression failure in CVS HEAD
On Fri, 2003-03-07 at 17:05, Doug McNaught wrote: > Neil Conway <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] regression failure in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
