Skip site navigation (1) Skip section navigation (2)

Re: beta3 Solaris 7 (SPARC) port report

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: Frank Joerdens <frank(at)joerdens(dot)de>, <prlw1(at)cam(dot)ac(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: beta3 Solaris 7 (SPARC) port report
Date: 2001-01-26 18:41:54
Message-ID: Pine.LNX.4.30.0101261911080.769-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Ross J. Reedstrom writes:

> Hmm, multiple processors, and lots of IPC: I've got a bad feeling
> about this.

Although I'm not absolutely certain, the systems on which I had this
problem were not multi-processor, they were just plain-old workstations in
a university computer lab.  At the time (7.0 beta) I had attributed this
problem to the possibly supicious nature of the /tmp partition, since Marc
didn't have any such problems with his Solaris boxes.

After reading Pete Forman's anecdote I looked around some more and found
this:

http://www.cise.ufl.edu/depot/doc/postfix/HISTORY

19990321

        Workaround: from now on, Postfix on Solaris uses stream
        pipes instead of UNIX-domain sockets. Despite workarounds,
        the latter were causing more trouble than anything else on
        all systems combined.


There are also some reports that indicate problems in this direction at
http://www.landfield.com/faqs/usenet/software/inn-faq/part2/.


Conclusion: Don't use it.

-- 
Peter Eisentraut      peter_e(at)gmx(dot)net       http://yi.org/peter-e/


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-01-26 18:54:40
Subject: Re: Open 7.1 items
Previous:From: Tom LaneDate: 2001-01-26 18:30:16
Subject: Re: This script will crash the connection

pgsql-general by date

Next:From: Tom LaneDate: 2001-01-26 18:49:43
Subject: Re: Performance: Unix sockets vs. TCP/IP sockets
Previous:From: Steve LeibelDate: 2001-01-26 18:29:10
Subject: Re: Connection pooling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group