Tom Lane wrote:

Yeah. I think I'd be more concerned by core regression failures than contrib build failures - especially as they are often likely to have more far reaching consequences.

Agreed.  I guess that the order of importance of the pieces you have is

        build main (this includes building PLs)
        run main tests
        run PL tests
        build contrib
        run contrib tests

That's almost what we do, but it's a bit more complex. Slightly simplified, the sequence runs something like this (PL checks only run on HEAD or branches >8.0):

 make check
 cd contrib && make
 make install
 cd $installdir && bin/initdb --no-locale data
 cd $installdir && bin/pg_ctl -D data -w start
 make installcheck
 cd src/pl && make installcheck
 cd contrib && make installcheck
 cd $installdir && bin/pg_ctl -D data stop

I'm not sure where the proposed-to-be-added multibyte regression tests
go in this order.  On practical grounds I would put them last; I rather
suspect that porting failures in that code will be rare.  Could be wrong

Yes, that makes sense. I don't know when I'll get time to make that happen though.

It's slightly annoying that the PLs are built as part of the main build;
I would rather run the main tests and then try to build and test the PLs
(that is, the ones that have external dependencies --- plpgsql can be
treated as part of the core for our purposes here).  Not sure if it's
worth hacking the makefiles to make that possible.

I don't think so.



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to