Re: Solaris/Sparc: Regression test fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Stefan Brozinski" <Stefan(dot)Brozinski(at)materna(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Solaris/Sparc: Regression test fails
Date: 2002-01-30 16:09:15
Message-ID: 23672.1012406955@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Stefan Brozinski" <Stefan(dot)Brozinski(at)materna(dot)de> writes:
> Reviewing the files in ./src/test/regress/results shows that tests
> (timestamp,interval,abstime) displayed the same symptom:

> psql: connectDBStart() -- connect() failed: Connection refused
> Is the postmaster running locally
> and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?

Solaris is known to have problems with the parallel regression tests
when running them via Unix-socket connections. If you tweak the
pg_regress.sh script to use TCP connections (there is already a case
statement that does that for some other platforms that haven't got Unix
sockets at all), you should find that it passes.

The underlying difficulty seems to be that Solaris rigidly enforces the
listen-queue limit for Unix sockets, and the postmaster isn't able to
shuffle off connections to child processes fast enough when the
regression script hits it with 20 nigh-simultaneous connection requests.
This should be alleviated in 7.2, which both increases the listen()
parameter and has the postmaster fork almost immediately.

You could try increasing the value passed to listen() in
src/backend/libpq/pqcomm.c if you want to verify this theory.
Or install 7.2rc2.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-01-30 16:12:05 Re: process exited with status 11 after XLogFlush: request is not satisfied
Previous Message Francisco Reyes 2002-01-30 16:07:43 Shortening time of vacuum analyze