Solaris/Sparc: Regression test fails

Started by Stefan Brozinskiabout 24 years ago2 messagesgeneral
Jump to latest
#1Stefan Brozinski
Stefan.Brozinski@materna.de

Hi!

I have just installed postgresql-7.1.3 on a Solaris 8 computer. I am
entirely new to postgresql, so I just typed

./configure
gmake
gmake check

Here, some of the regression tests failed. The regression tests that failed
are:

- timestamp
- interval
- abstime
- test horology
- random (ignored)
- test misc

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'?

I have no idea what psql wants to tell me here.

The other test results show diffs between expected/found output. Anyone
interested in the regression diffs (192 KB)?

Best regards,
Stefan

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Stefan Brozinski (#1)
Re: Solaris/Sparc: Regression test fails

"Stefan Brozinski" <Stefan.Brozinski@materna.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