Обсуждение: beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Tue, Jan 23, 2001 at 11:57:52AM -0500, Tom Lane wrote:
[ . . . ]
> After you build PG and test it, send us a port report, and we'll add
> Solaris 7 to the list of recently tested platforms. That's how it
> works ...
The installation by simply running configure, make, make install went
completely smoothly, no hassle whatsoever (except for the
flex-is-not-present warning which I think you can ignore)!
The system is, to be precise:
$ uname -a
SunOS [hostname] 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4
I did encounter some _weird_ stuff with the regression tests. Does that
not work via make check (the 'standalone' variety) when you've already
typed make install (on Linux it does!)?? Make installcheck seems to
produce non-failures semi-reliably (why does the random test not fail on
the 1st try, but on the 2nd, and then again not on the 3rd???). Below
are the dirty details.
As to what is mentioned in the Admin Guide about Solaris' default
settings for shared memore being too low, at least on the machine I am
testing on it is set to 4 GB!
$ cat /etc/system |grep shm
* exclude: sys/shmsys
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmmin = 1
set shmsys:shminfo_shmmni = 100
set shmsys:shminfo_shmseg = 10
Cheers, Frank
------------------ begin dirty details ------------------
I can start, connect, create databases etc.. However, running the
regression tests gives 4 failed out of 76:
reltime ... FAILED tinterval ... FAILED
test horology ... FAILED
test misc ... FAILED
I checked the timezone issue mentioned in the src/test/regress/README
file. The command
$ env TZ=PST8PDT date
returns 'Wed Jan 24 11:19:02 PST 2001', 9 hrs back, which is the time
difference between here and California, so I guess that is OK.
Running the tests on my Linux box gives no failed tests. Must I assume
that those failed tests indicate some issue that is is detrimental to
the proper functioning of the server on this Solaris installation? Do
you want the regression.diffs?
I also tried using the Sun compiler, which didn't work at all.
. . . [ goes away to do more testing ] . . .
What's really weird, I just ran ./configure, make, make install, make
check again, again with 4 failed, but different ones!
tinterval ... FAILED inet ... FAILED comments ... FAILED
test misc ... FAILED
2 things were different: a) I set the compiler explicitly to
/usr/local/bin/gcc via the CC environment variable and b) I used the
default prefix this time. I'll try again with the old settings.
. . . [ goes away to do more testing ] . . .
make distclean
./configure --prefix=/usr/db/pgsql
make
make check
produces 6 out of 76 this time! They are:
date ... FAILED type_sanity ... FAILED opr_sanity ... FAILED arrays
... FAILED btree_index ... FAILED
test misc ... FAILED
It looks progressively worse. I'll remove the source tree and start from scratch.
. . . [ goes away to do more testing ] . . .
6 out of 76 again, but different ones . . .
interval ... FAILED abstime ... FAILED comments ... FAILED oidjoins
... FAILED
test horology ... FAILED
test misc ... FAILED
. . . [ goes away to do more testing ] . . .
This time with the already installed database after initdb:
$ make installcheck
now I get scary stuff like:
----------------------- begin scary stuff -----------------------
test int2 ... ERROR: pg_atoi: error in "34.5": can't
parse ".5"
ERROR: pg_atoi: error reading "100000": Result too large
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
ok
test int4 ... ERROR: pg_atoi: error in "34.5": can't
parse ".5"
ERROR: pg_atoi: error reading "1000000000000": Result too large
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
ok
test int8 ... ok
test oid ... ERROR: oidin: error in "asdfasd": can't
parse "asdfasd"
ERROR: oidin: error in "99asdfasd": can't parse "asdfasd"
ok
test float4 ... ERROR: Bad float4 input format --
overflow
----------------------- end scary stuff -----------------------
However, it works! All 76 tests pass.
. . . [ goes away to do more testing ] . . .
running make installcheck again gives:
test random ... failed (ignored)
. . . [ goes away to do more testing ] . . .
All 76 tests pass.
------------------ end dirty details ------------------
Frank Joerdens writes: [randomly varying set of regression tests fail] > Running the tests on my Linux box gives no failed tests. Must I assume > that those failed tests indicate some issue that is is detrimental to > the proper functioning of the server on this Solaris installation? Do > you want the regression.diffs? Could you go into src/test/regress/pg_regress.sh and edit around line 162 #case $host_platform in # *-*-qnx* | *beos*) unix_sockets=no;; # *) # unix_sockets=yes;; #esac (i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'. I have experienced before that Unix sockets will cause random connection abortions on Solaris, which will cause the regression tests to fail arbitrarily. > I also tried using the Sun compiler, which didn't work at all. details on "didn't work" requested... > now I get scary stuff like: > > ----------------------- begin scary stuff ----------------------- > test int2 ... ERROR: pg_atoi: error in "34.5": can't > parse ".5" > ERROR: pg_atoi: error reading "100000": Result too large > ERROR: pg_atoi: error in "asdf": can't parse "asdf" This is normal. The regression tests sometimes involve intentional invalid input. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, Jan 25, 2001 at 12:42:45AM +0100, Peter Eisentraut wrote: > Frank Joerdens writes: > > [randomly varying set of regression tests fail] > > > Running the tests on my Linux box gives no failed tests. Must I assume > > that those failed tests indicate some issue that is is detrimental to > > the proper functioning of the server on this Solaris installation? Do > > you want the regression.diffs? > > Could you go into src/test/regress/pg_regress.sh and edit around line 162 > > #case $host_platform in > # *-*-qnx* | *beos*) > unix_sockets=no;; > # *) > # unix_sockets=yes;; > #esac > > (i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'. 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). > > I have experienced before that Unix sockets will cause random connection > abortions on Solaris [ . . . ] Isn't that _really_ bad? Random connection abortions when going over Unix sockets?? My app does _all_ the connecting over Unix sockets?! > > I also tried using the Sun compiler, which didn't work at all. > > details on "didn't work" requested... ------------------ begin details ------------------ $ export CC=CC $ echo $CC CC $ ./configure creating cache ./config.cache checking host system type... sparc-sun-solaris2.7 checking which template to use... solaris checking whether to build with locale support... no checking whether to build with recode support... no checking whether to build with multibyte character support... no checking whether to build with Unicode conversion support... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... CC checking whether the C compiler (CC ) works... yes checking whether the C compiler (CC ) is a cross-compiler... no checking whether we are using GNU C... no checking whether CC accepts -g... yes using CFLAGS=-v checking whether the C compiler (CC -Xa -v ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. ------------------ end details ------------------ Cheers, Frank
Worked fine for me... % uname -a SunOS lancelot 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCstation-4 % ls -l -rw-r--r-- 1 bpalmer staff 32860160 Jan 23 16:45 postgresql-snapshot.tar ... ... ... transactions ... ok random ... failed (ignored) portals ... ok ... ... ... ==================================================75 of 76 tests passed, 1 failed test(s) ignored. ================================================== On Thu, 25 Jan 2001, Peter Eisentraut wrote: > Frank Joerdens writes: > > [randomly varying set of regression tests fail] > > > Running the tests on my Linux box gives no failed tests. Must I assume > > that those failed tests indicate some issue that is is detrimental to > > the proper functioning of the server on this Solaris installation? Do > > you want the regression.diffs? > > Could you go into src/test/regress/pg_regress.sh and edit around line 162 > > #case $host_platform in > # *-*-qnx* | *beos*) > unix_sockets=no;; > # *) > # unix_sockets=yes;; > #esac > > (i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'. > > I have experienced before that Unix sockets will cause random connection > abortions on Solaris, which will cause the regression tests to fail > arbitrarily. > > > I also tried using the Sun compiler, which didn't work at all. > > details on "didn't work" requested... > > > now I get scary stuff like: > > > > ----------------------- begin scary stuff ----------------------- > > test int2 ... ERROR: pg_atoi: error in "34.5": can't > > parse ".5" > > ERROR: pg_atoi: error reading "100000": Result too large > > ERROR: pg_atoi: error in "asdf": can't parse "asdf" > > This is normal. The regression tests sometimes involve intentional > invalid input. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > b. palmer, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
Frank Joerdens writes: > > I have experienced before that Unix sockets will cause random connection > > abortions on Solaris [ . . . ] > > Isn't that _really_ bad? Random connection abortions when going over > Unix sockets?? My app does _all_ the connecting over Unix sockets?! That's bad, for sure. Maybe you can check for odd conditions surrounding the /tmp directory, like is it on NFS, permission problems, mount options. Or is there something odd in the kernel configuration? If I'm counting correctly this is the third independent report of this problem, which is scary. > > > I also tried using the Sun compiler, which didn't work at all. > > > > details on "didn't work" requested... > > ------------------ begin details ------------------ > $ export CC=CC Using a C++ compiler to compile C code won't work. You probably meant CC=cc and CXX=CC. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote: > Frank Joerdens writes: > > > > I have experienced before that Unix sockets will cause random connection > > > abortions on Solaris [ . . . ] > > > > Isn't that _really_ bad? Random connection abortions when going over > > Unix sockets?? My app does _all_ the connecting over Unix sockets?! > > That's bad, for sure. Maybe you can check for odd conditions surrounding > the /tmp directory, like is it on NFS, permission problems, mount options. I don't have neither root nor physical access to this machine, hence my options are kinda limited. However, the sysadmin told me that most of the storage space on this box is mounted over a fibre channel (I only have a very hazy notion of what exactly that might be) from a "storage server" which is allegedly as fast as a local SCSI disk. > Or is there something odd in the kernel configuration? If I'm counting > correctly this is the third independent report of this problem, which is > scary. I'll question the sysadmin about that. But why does make installcheck work? Because it goes over TCP/IP sockets by default? > > > > > I also tried using the Sun compiler, which didn't work at all. > > > > > > details on "didn't work" requested... > > > > ------------------ begin details ------------------ > > $ export CC=CC > > Using a C++ compiler to compile C code won't work. You probably meant > CC=cc and CXX=CC. When I do that, make fails with the following error (after giving lots of warnings): "pg_dump.c", line 1063: warning: Function has no return statement : main cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o common.o common.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_archiver.o pg_backup_archiver.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_db.o pg_backup_db.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_custom.o pg_backup_custom.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_files.o pg_backup_files.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_null.o pg_backup_null.c "pg_backup_null.c", line 90: controlling expressions must have scalar type cc: acomp failed for pg_backup_null.c make[3]: *** [pg_backup_null.o] Error 2 make[3]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src' make: *** [all] Error 2 Regards, Frank
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote: > Frank Joerdens writes: > > > > I have experienced before that Unix sockets will cause random connection > > > abortions on Solaris [ . . . ] > > > > Isn't that _really_ bad? Random connection abortions when going over > > Unix sockets?? My app does _all_ the connecting over Unix sockets?! > > That's bad, for sure. Maybe you can check for odd conditions surrounding > the /tmp directory, like is it on NFS, permission problems, mount options. I just typed $ mount and I get /tmp on swap read/write/setuid on Mon Jan 22 16:39:32 2001 for the /tmp directory, which looks distinctly odd to me. What kind of device is swap (I know what swap is normally but I didn't know you could mount stuff there . . . )?? Regards, Frank
Frank Joerdens writes: > > That's bad, for sure. Maybe you can check for odd conditions surrounding > > the /tmp directory, like is it on NFS, permission problems, mount options. > > I don't have neither root nor physical access to this machine, hence my > options are kinda limited. Entering 'mount' should tell you. > I'll question the sysadmin about that. But why does make installcheck > work? Because it goes over TCP/IP sockets by default? No. Presumably because it does not run more than one test in parallel. > "pg_backup_null.c", line 90: controlling expressions must have scalar type > cc: acomp failed for pg_backup_null.c Line 90 has a comment in my copy. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Frank Joerdens <frank@joerdens.de> writes: > I just typed > > $ mount > > and I get > > /tmp on swap read/write/setuid on Mon Jan 22 16:39:32 2001 > > for the /tmp directory, which looks distinctly odd to me. What kind of > device is swap (I know what swap is normally but I didn't know you could > mount stuff there . . . )?? That is a tmpfs file system which uses swap space for /tmp storage. Both swap usage and /tmp compete for the same partition on the disk. If you have a lot of swapping programs, you don't get to put much in /tmp. If you have a lot of files in /tmp, you don't get to run many programs. As far as I can recall, this is a Sun specific thing. It's a reasonable idea on a stable system. It's a pretty crummy idea on a development system, or one with unpredictable loads. My experience is that either something goes crazy and fills up /tmp and then you can't run anything else and you have to reboot, or something goes crazy and fills up swap and then you can't write any /tmp files and daemon processes start to silently die and you have to reboot. Ian
Frank Joerdens writes: > I just typed > > $ mount > > and I get > > /tmp on swap read/write/setuid on Mon Jan 22 16:39:32 2001 That's sufficiently suspicious. Perhaps you could try to change the definition of DEFAULT_PGSOCKET_DIR in src/include/config.h[.in] to something that's on a real disk. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote: [ . . . ] > > for the /tmp directory, which looks distinctly odd to me. What kind of > > device is swap (I know what swap is normally but I didn't know you could > > mount stuff there . . . )?? > > That is a tmpfs file system which uses swap space for /tmp storage. > Both swap usage and /tmp compete for the same partition on the disk. > If you have a lot of swapping programs, you don't get to put much in > /tmp. If you have a lot of files in /tmp, you don't get to run many > programs. > > As far as I can recall, this is a Sun specific thing. > > It's a reasonable idea on a stable system. It's a pretty crummy idea > on a development system, or one with unpredictable loads. My > experience is that either something goes crazy and fills up /tmp and > then you can't run anything else and you have to reboot, or something > goes crazy and fills up swap and then you can't write any /tmp files > and daemon processes start to silently die and you have to reboot. Very peculiar, or crummy, indeed. This is system is not used by anyone else besides myself at the moment (cuz it's just being built up), as far a I can tell, and is ludicrously overpowered (3 CPUs, 768 MB RAM) for the mundane uses I am subjecting it to (installing and testing Postgresql). Regards, Frank
On Thu, Jan 25, 2001 at 09:47:16PM +0100, Frank Joerdens wrote: > On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote: > [ . . . ] > > > for the /tmp directory, which looks distinctly odd to me. What kind of > > > device is swap (I know what swap is normally but I didn't know you could > > > mount stuff there . . . )?? > > > > That is a tmpfs file system which uses swap space for /tmp storage. > > Both swap usage and /tmp compete for the same partition on the disk. > > If you have a lot of swapping programs, you don't get to put much in > > /tmp. If you have a lot of files in /tmp, you don't get to run many > > programs. > > > > As far as I can recall, this is a Sun specific thing. > > > > It's a reasonable idea on a stable system. It's a pretty crummy idea > > on a development system, or one with unpredictable loads. My > > experience is that either something goes crazy and fills up /tmp and > > then you can't run anything else and you have to reboot, or something > > goes crazy and fills up swap and then you can't write any /tmp files > > and daemon processes start to silently die and you have to reboot. > > Very peculiar, or crummy, indeed. This is system is not used by anyone > else besides myself at the moment (cuz it's just being built up), as far > a I can tell, and is ludicrously overpowered (3 CPUs, 768 MB RAM) for > the mundane uses I am subjecting it to (installing and testing > Postgresql). I doubt you can blame any problems on tmpfs, here. tmpfs has been in Solarix for many years, and has had plenty of time to stabilize. With 768M of RAM and running only PG you not using any swap space at all, and unix sockets don't use any appreciable space either, so the conflicts Ian describes are impossible in your case. Nathan Myers ncm@zembu.com
Frank Joerdens <frank@joerdens.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? (Else it'd not be random...) See the pages on interpreting
regression test results in the admin guide.
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.
regards, tom lane
Peter Eisentraut writes:> Frank Joerdens writes:> > > > I have experienced before that Unix sockets will cause random> >> connection abortions on Solaris [ . . . ]> >> > Isn't that _really_ bad? Random connection abortions when going> > overUnix sockets?? My app does _all_ the connecting over Unix> > sockets?!> > That's bad, for sure. Maybe you can checkfor odd conditions> surrounding the /tmp directory, like is it on NFS, permission> problems, mount options. Or is theresomething odd in the kernel> configuration? If I'm counting correctly this is the third> independent report of thisproblem, which is scary. I'm not sure if you counted me. I also observed that Unix sockets cause the parallel tests to fail in random places on Solaris. We had a similar problem porting a product that uses a lot of IPC to Solaris. There were failures involving the overloading of the Unix domain sockets. We took the code to Sun and they were unable to resolve the problems. It should have been possible to tune the kernel to provide more resources. However it turns out that some of the parameters that we wanted to tune were ignored in favour of hard coded values. In the end we rewrote our code to use Internet domain sockets (AF_INET). BTW, owing to a DNS error email to me has bounced over the last couple of days. It should be okay now if anything needs to be resent. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
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@joerdens.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
Frank Joerdens <frank@joerdens.de> writes:
> Now I get:
> select_distinct_on ... FAILED
> select_implicit ... FAILED
> random ... failed (ignored)
> portals ... FAILED
> test misc ... FAILED
Reporting a regression failure this way is pretty unhelpful. What are
the actual diffs (regression.diffs)? What shows up in the postmaster
log (logs/postmaster.log)?
regards, tom lane
On Fri, Jan 26, 2001 at 05:03:13PM +0100, Frank Joerdens wrote: > > 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. Hmm, multiple processors, and lots of IPC: I've got a bad feeling about this. Nothing solid (don't do a lot with Solaris), but there are a _lot_ of gotchas in getting that combo right, many of which _kill_ performance for the normal case to get correct behavior in an edge case. I could imagine Sun missing one or two, and not catching it (or actively ignoring it, to get better CPU utilization) Since it seems to hit only when using Unix domain sockets, I'd take a wild guess that explicit use of shared memory and Unix domain sockets are stepping on each other in a multiprocessor environment. Invoking Inet sockets gets more of the networking code in play, which is usually more heavily tested in such an environment. Since it's just you and the sysadmin: any chance you could bring the system up uniprocessor (I don't even know if this is _possible_ with Sun hardware, let alone how hard) and run the regressions some more? If that makes it go away, I'd say it pretty well points straight into the Solaris kernel. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
On Fri, Jan 26, 2001 at 11:15:45AM -0500, Tom Lane wrote: > Frank Joerdens <frank@joerdens.de> writes: > > Now I get: > > > select_distinct_on ... FAILED > > select_implicit ... FAILED > > random ... failed (ignored) > > portals ... FAILED > > test misc ... FAILED > > Reporting a regression failure this way is pretty unhelpful. Sorry. My thinking was that the bottom line here is the very non-reproducability of particular results. No two regression test failures where identical of the couple dozen or so I conducted, and hence it wouldn't make all that much sense to analyze any single test all by itself. As I wrote earlier, I don't have neither physical nor root access to this box. Moreover, the sysadmin tells me that he didn't install the OS himself, a friend of his did, because he himself was on holiday. There may well be something very fishy about the OSs configuration, but I wouldn't have the first notion as to where to start looking. It _appears_ that setting DEFAULT_PGSOCKET_DIR somewhere else besides /tmp has some positive effect, but that ain't conclusive. > What are > the actual diffs (regression.diffs)? What shows up in the postmaster > log (logs/postmaster.log)? Those results were overwritten by the last 10 tests that didn't show any errors, so I can't retrieve them, now. Regards, Frank
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@gmx.net http://yi.org/peter-e/
On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote: > Frank Joerdens <frank@joerdens.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? (Else it'd not be random...) See the pages on interpreting > regression test results in the admin guide. > > 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) Cheers, Patrick
Ross J. Reedstrom writes:> Hmm, multiple processors, and lots of IPC:> [snip]> Since it's just you and the sysadmin: anychance you could bring> the system up uniprocessor (I don't even know if this is _possible_> with Sun hardware, let alonehow hard) and run the regressions some> more? If that makes it go away, I'd say it pretty well points> straight intothe Solaris kernel. My observations of Solaris UNIX domain socket problems were on single processor machines. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.