Re: beta3 Solaris 7 (SPARC) port report

On Fri, Jan 26, 2001 at 03:29:59PM +0000, Patrick Welche wrote:
> On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote:
> > Frank Joerdens <frank(at)joerdens(dot)de> writes:
> > > I just did that and ran make check 4 times. 3 times went completely
> > > smoothly, once I had random fail. This is the same behaviour that I saw
> > > when running make installcheck (76 successful most of the time,
> > > sometimes you get 75 out of 76 with random being the one that fails).
> >
> > Er, you do realize that the random test is *supposed* to fail every so
> > often?

I do. I just included the info for completeness' sake.

> > What troubles me is the nonrepeatable failures you saw on other tests.
> > As Peter says, if "make installcheck" (serial tests) is perfectly solid
> > and "make check" (parallel tests) is not, that suggests some kind of
> > interprocess locking problem. But we haven't heard about any such issue
> > on Solaris.
>
> Or simply running out of processes - check maxproc? (Deleted beginning of
> this thread, so may have missed something)

There is no load at all on this server at the moment. The sysadmin and
myself are currently the only people accessing a brand new UltraSPARC with 3
CPUs and 3/4 GB of RAM to install stuff.

Whatever the reason for it, Peter's suggestion at least seems to
mitigate the issue with the regression tests. I've set DEFAULT_PGSOCKET_DIR
in src/include/config.h.in to /usr/db/pgsql/tmp (/usr/db/pgsql is the
postgres user's home dir and the install dir for Postgres). Running make
check after that gives:

1: none failed
2: random ... failed (ignored)
3: Oh. What's the expression (in German you'd say 'Zu frueh gefreut.')
here. Now I get:

select_distinct_on ... FAILED
select_implicit ... FAILED
random ... failed (ignored)
portals ... FAILED
test misc ... FAILED

Typing

$ ps -a

I can see that 2 postgres processes are still active . . . ?? And
/usr/db/pgsql/tmp does not contain any lock file??? I killed those 2 and
ran make check again:

4: none failed
5: random ... failed (ignored)
6: none failed
7: random ... failed (ignored)
8: none failed
9: none failed
9: comments ... FAILED

Hm. Bizarre. The issue isn't solved but it definitely looks better than
before (also, the sysadmin just told me that /tmp is cleaned out
nightly anyway by cron). I'm gonna test it over TCP/IP sockets again,
and if that works, stick with those:

When setting unix_sockets=no; for any plattform in
src/test/regress/pg_regress.sh, 7 consecutive tests showed no errors.
I'll just connect to the server over TCP/IP.

Regards, Frank