Regression tests for OBSD scrammed..

Is this CVS or 7.1.X?

My nightly regression tests for OBSD failed for i386 and sparc. Attached
is the regression.diff, I don't know what to make of it.. Looks like
problems w/ foreign keys.

...
parallel group (5 tests): portals_p2 rules select_views alter_table
foreign_key
select_views ... ok
alter_table ... FAILED
portals_p2 ... ok
rules ... ok
foreign_key ... FAILED
parallel group (3 tests): limit temp plpgsql
...

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Content-Description:

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Yes, I see it too. Must have been one of the patches I applied
yesterday. Not sure which one.

My nightly regression tests for OBSD failed for i386 and sparc. Attached
is the regression.diff, I don't know what to make of it.. Looks like
problems w/ foreign keys.

...
parallel group (5 tests): portals_p2 rules select_views alter_table
foreign_key
select_views ... ok
alter_table ... FAILED
portals_p2 ... ok
rules ... ok
foreign_key ... FAILED
parallel group (3 tests): limit temp plpgsql
...

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Content-Description:

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Is this CVS or 7.1.X?

My nightly regression tests for OBSD failed for i386 and sparc. Attached
is the regression.diff, I don't know what to make of it.. Looks like
problems w/ foreign keys.

Doh, sorry all.

CVS as of 3am last night..

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Is this CVS or 7.1.X?

My nightly regression tests for OBSD failed for i386 and sparc. Attached
is the regression.diff, I don't know what to make of it.. Looks like
problems w/ foreign keys.

Doh, sorry all.

CVS as of 3am last night..

OK, do an initdb and watch the errors disapper. :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, do an initdb and watch the errors disapper. :-)

Did someone forget to bump catversion.h?

I didn't notice any recent commits that sounded like they'd need to
force an initdb, but maybe I missed something.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, do an initdb and watch the errors disapper. :-)

Did someone forget to bump catversion.h?

I didn't notice any recent commits that sounded like they'd need to
force an initdb, but maybe I missed something.

I will bump it now. I didn't see anything either, but initdb fixed my
regression test errors.

Catversiion updated. Done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will bump it now. I didn't see anything either, but initdb fixed my
regression test errors.

That was probably a waste of effort. I just finished pulling down and
recompiling CVS tip. I see no regression failures, either using a data
directory left over from yesterday or with a fresh initdb. So I don't
think it's a catalog compatibility issue. I suspect a "make distclean"
and "make all" might have more to do with fixing it.

Alternatively, we might have a genuine portability problem lurking.
Does either of you still see a problem after doing a full rebuild?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will bump it now. I didn't see anything either, but initdb fixed my
regression test errors.

That was probably a waste of effort. I just finished pulling down and
recompiling CVS tip. I see no regression failures, either using a data
directory left over from yesterday or with a fresh initdb. So I don't
think it's a catalog compatibility issue. I suspect a "make distclean"
and "make all" might have more to do with fixing it.

Alternatively, we might have a genuine portability problem lurking.
Does either of you still see a problem after doing a full rebuild?

I don't.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Hmm ... Bruce, were you doing serial or parallel regress tests?
I'm finding that the serial tests work and the parallels blow up.
It might be that this is because of my anti-lseek hacking, but
I kinda doubt it because the failures occur right about where
bpalmer saw trouble with last night's CVS ...

regards, tom lane

Hmm ... Bruce, were you doing serial or parallel regress tests?
I'm finding that the serial tests work and the parallels blow up.
It might be that this is because of my anti-lseek hacking, but
I kinda doubt it because the failures occur right about where
bpalmer saw trouble with last night's CVS ...

I was doing serial.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I was doing serial.

And ... ?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I was doing serial.

And ... ?

It is fine now. I did see the error, but an initdb fixed it. I am 100%
OK now.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I was doing serial.

Try the parallels a few times, and you *will* see it fail.

Reason: Stephan added a bunch of tests to alter_table.sql that
create/modify/delete tables named pktable and fktable.

Unfortunately, foreign_key.sql uses those same names for its
test tables ... and the parallel tests run these two tests
in parallel. Ooops.

Possible solutions: (a) rename tables in one test or the other,
or (b) use TEMPORARY tables in one test or the other. I kinda
like (b), just to exercise temp tables in some interesting new
ways. Whaddya think?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I was doing serial.

Try the parallels a few times, and you *will* see it fail.

Reason: Stephan added a bunch of tests to alter_table.sql that
create/modify/delete tables named pktable and fktable.

Unfortunately, foreign_key.sql uses those same names for its
test tables ... and the parallel tests run these two tests
in parallel. Ooops.

Possible solutions: (a) rename tables in one test or the other,
or (b) use TEMPORARY tables in one test or the other. I kinda
like (b), just to exercise temp tables in some interesting new
ways. Whaddya think?

Sounds good to me, and makes sense.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Alternatively, we might have a genuine portability problem lurking.
Does either of you still see a problem after doing a full rebuild?

Sorry this is late, but..

I was still having the problem, even after a rm -rf of pgsql and a cvs co
of tip. Tom, let me know if you need any more information. I'll speak
up again if tonight's regression tests still fail.

- brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Tom says is the parallel regresion tests, and he knows the cause.

Alternatively, we might have a genuine portability problem lurking.
Does either of you still see a problem after doing a full rebuild?

Sorry this is late, but..

I was still having the problem, even after a rm -rf of pgsql and a cvs co
of tip. Tom, let me know if you need any more information. I'll speak
up again if tonight's regression tests still fail.

- brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Possible solutions: (a) rename tables in one test or the other,
or (b) use TEMPORARY tables in one test or the other. I kinda
like (b), just to exercise temp tables in some interesting new
ways. Whaddya think?

I have a preference for (a). If we want to test temporary tables, let's
have a test which does that. But having a possible name conflict mixed
in to another test seems to be asking for trouble, or at least does not
decouple things as much as they could be.

There is a benefit to having complex tests (a great benefit) but without
also having decoupled tests the diagnostic benefit is not as clear cut
imho.

Bruce, would you have time to generate a regression test for temporary
tables? If we don't have one now, we should.

- Thomas

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

Possible solutions: (a) rename tables in one test or the other,
or (b) use TEMPORARY tables in one test or the other. I kinda
like (b), just to exercise temp tables in some interesting new
ways. Whaddya think?

I have a preference for (a). If we want to test temporary tables, let's
have a test which does that. But having a possible name conflict mixed
in to another test seems to be asking for trouble, or at least does not
decouple things as much as they could be.

But we already have a ton of regress tests that work on nonconflicting
table names. Seems like we add coverage if we try a few that are doing
parallel uses of plain and temp tables of the same name.

Bruce, would you have time to generate a regression test for temporary
tables? If we don't have one now, we should.

There is one. But as a single test, it proves nothing about whether
temp tables conflict with similarly-named tables from the point of view
of another backend.

regards, tom lane

Possible solutions: (a) rename tables in one test or the other,
or (b) use TEMPORARY tables in one test or the other. I kinda
like (b), just to exercise temp tables in some interesting new
ways. Whaddya think?

I have a preference for (a). If we want to test temporary tables, let's
have a test which does that. But having a possible name conflict mixed
in to another test seems to be asking for trouble, or at least does not
decouple things as much as they could be.

There is a benefit to having complex tests (a great benefit) but without
also having decoupled tests the diagnostic benefit is not as clear cut
imho.

Bruce, would you have time to generate a regression test for temporary
tables? If we don't have one now, we should.

We already have one as temp.out. Is there something more it should be
testing?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026