Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I think you need a dual cpu machine to see the failures.
>
> I was wondering about that myself, but we shouldn't fixate on that
> assumption without more evidence. There could be some other factor
> explaining why I can't reproduce it. A couple of questions for both
> of you:
> - what configure options are you using?
configure \ --with-x \ --with-threads \ --with-tcl \ --with-perl \ --with-python \
--enable-pltcl-unknown\ --with-tclconfig=/u/lib \ --with-tkconfig=/u/lib \ --enable-cassert \
--with-includes="/usr/local/include/readline/usr/contrib/include" \ --with-libraries="/usr/local/lib
/usr/contrib/lib"\ --enable-locale \ --enable-multibyte \ --with-recode \ --with-openssl
> - can you reproduce the problem with serial tests (make installcheck)?
No, I have never seen a serial failure, and when I get a paralell
failure, I run the serial to make sure it is just the paralell test, and
serial always passes.
> - exactly how repeatable is it --- when it fails, is it always at the
> same places, or do the failures move around?
No, different, as reported by Robert, but it usually has to do with the
contraint, trigger, and sanity tests. I assume we just had a dependency
in the paralell regression tests and we just need to do an adjustment,
but looking at the diffs more closely, I see it is more serious.
> It would also be good to find out exactly where the failures are coming
> from. Please try running the tests with LOG_ERROR_VERBOSITY set to
> VERBOSE (probably the easiest way to hack this in make check's temp
> installation is to modify src/backend/utils/misc/postgresql.conf.sample).
> Then the postmaster log file created by make check will show the elog
> calls' locations.
OK.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
