Thread: Regression tests for OBSD scrammed..
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
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, Pennsylvania19026
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, Pennsylvania19026
> 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, Pennsylvania19026
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, Pennsylvania19026
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, Pennsylvania19026
> 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, Pennsylvania19026
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
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, Pennsylvania19026
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, Pennsylvania19026
> 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, Pennsylvania19026
> > 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, Pennsylvania19026
My regression tests ran clean this morning. Thanks guys. - brandon b. palmer, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
> My regression tests ran clean this morning. Thanks guys. > I figured out why recompile/initdb fixed it for me. I saw the same compile errors you did because I had patched my expected.out files are part of applying a patch. I had not recompiled, so I saw the same failures you did. I did a recompile and initdb just to clean everything out, and it went away. My failures were part of patch application, while yours where from the parallel regression tests used with the new patch. -- 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, Pennsylvania19026