Re: [HACKERS] regression failure in CVS HEAD

2003-03-09 Thread Tom Lane
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

2003-03-09 Thread Neil Conway
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

2003-03-08 Thread Tom Lane
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

2003-03-08 Thread Neil Conway
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

2003-03-08 Thread Joe Conway
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

2003-03-08 Thread Tom Lane
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

2003-03-08 Thread Rod Taylor
> 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

2003-03-07 Thread Tom Lane
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

2003-03-07 Thread Rod Taylor
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

2003-03-07 Thread Doug McNaught
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