Re: Re: [BUGS] Tests randomly failed - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: [BUGS] Tests randomly failed
Date
Msg-id Pine.LNX.4.30.0103271907460.1215-100000@peter.localdomain
Whole thread Raw
In response to Re: Re: [BUGS] Tests randomly failed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [BUGS] Tests randomly failed
List pgsql-hackers
Tom Lane writes:

> Alexander Klimov <ask@wisdom.weizmann.ac.il> writes:
> > Yes, it was really just incidence -- I try again, and 15 of 15 `make
> > check' passed with TCP sockets, but only 3 of 15 passed with UNIX
> > sockets. So, final decision is `Unix sockets are not relaible on Solaris'

What become up 'set maxuprc=256'?  I thought that made it work.  Could
other people try it or has it been disproven?

> So, shall we change pg_regress.sh to not use Unix sockets on Solaris?

This would hide problems during the test phase which would reappear in the
production phase, no?

> Perhaps for Solaris, go to TCP only if it's parallel mode?

Unfortunately, it's not possible to detect this globally, only when you're
actually parsing the schedule file and encouter a parallel group.  This
would mean running some tests this way and some tests another way.  That
might not be the worst of ideas, but it should be done on all platforms
then.  Additionally, it don't think it will really fix things, because
some tests that failed were not in a parallel group (and I firmly recall
that some of those were *not* follow-up failures).  I think it is more
related to a "high load" situation.


If I were a Solaris user and had a bit more insight into this problem I
would probably vote for #undef HAVE_UNIX_SOCKETS.  But I'm not...

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: docs toolchain appears broke?
Next
From: Alexander Klimov
Date:
Subject: Ultrix port