Re: beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]

I am faced with the task of installing, configuring, and tuning my
database, which is currently running under Linux, under Solaris 7 on a
brand-new and shiny Sun UltraSPARC (3 CPUs, 768 MB RAM), because the sysadmin at the site
hasn't used or installed PostgreSQL and would rather have me do it. Is
this actually supported? The FAQ (the one bundled with the 7.1 beta3
which I'll be using) lists only:

sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1

If it is supported (I don't suppose a little OS version number increment
would make a differnce here), I've never used Solaris or anything other
than Intel-based hardware and am looking for some info on what to watch
out for and consider when installing and tuning PostgreSQL on Solaris on
a SPARC plattform. Aside from the shared memory stuff in the Admin
Guide, I haven't found anything so far. Particularly, I would expect
that you could gain a significant performance boost from running the
database on a 64 bit plattform (without knowing exactly why, only
picking up on word-of-mouth and assorted hype on 64 bit architectures).
How do you get the most out of it? Would I use gcc or the native Sun
compiler (how do you control that anyway)?

Any pointers would be much appreciated.

Thanks, Frank

First, you read the installation instructions. Then, if specific problems
come up you send specific problem reports. But I think we have this
platform pretty much covered. Good luck.

Frank Joerdens writes:

> I am faced with the task of installing, configuring, and tuning my
> database, which is currently running under Linux, under Solaris 7 on a
> brand-new and shiny Sun UltraSPARC (3 CPUs, 768 MB RAM), because the sysadmin at the site
> hasn't used or installed PostgreSQL and would rather have me do it. Is
> this actually supported? The FAQ (the one bundled with the 7.1 beta3
> which I'll be using) lists only:
>
> sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1
>
> If it is supported (I don't suppose a little OS version number increment
> would make a differnce here), I've never used Solaris or anything other
> than Intel-based hardware and am looking for some info on what to watch
> out for and consider when installing and tuning PostgreSQL on Solaris on
> a SPARC plattform. Aside from the shared memory stuff in the Admin
> Guide, I haven't found anything so far. Particularly, I would expect
> that you could gain a significant performance boost from running the
> database on a 64 bit plattform (without knowing exactly why, only
> picking up on word-of-mouth and assorted hype on 64 bit architectures).
> How do you get the most out of it? Would I use gcc or the native Sun
> compiler (how do you control that anyway)?
>
> Any pointers would be much appreciated.
>
> Thanks, Frank
>
>

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

Frank Joerdens <frank(at)joerdens(dot)de> writes:
> I am faced with the task of installing, configuring, and tuning my
> database, which is currently running under Linux, under Solaris 7 on a
> brand-new and shiny Sun UltraSPARC (3 CPUs, 768 MB RAM), because the
> sysadmin at the site hasn't used or installed PostgreSQL and would
> rather have me do it. Is this actually supported? The FAQ (the one
> bundled with the 7.1 beta3 which I'll be using) lists only:

> sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1

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 ...

> Would I use gcc or the native Sun
> compiler (how do you control that anyway)?

Try 'em both --- set CC environment variable before running configure
to control configure's choice of compiler.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> > sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1
>
> 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 ...
>

We've had client running pgsql 7.0 on Solaris 7 since early May 2000. No
problems at all.

> > Would I use gcc or the native Sun
> > compiler (how do you control that anyway)?
>
> Try 'em both --- set CC environment variable before running configure
> to control configure's choice of compiler.

Most Solaris 7 installations I've seen come without the Sun compiler as
standard, so gcc is probably your safest bet. You probably have to
/usr/ccs/bin to your path to get ar and friends.

regards,

Gunnar

El Mar 23 Ene 2001 12:38, Frank Joerdens escribió:
> I am faced with the task of installing, configuring, and tuning my
> database, which is currently running under Linux, under Solaris 7 on a
> brand-new and shiny Sun UltraSPARC (3 CPUs, 768 MB RAM), because the
> sysadmin at the site hasn't used or installed PostgreSQL and would rather
> have me do it. Is this actually supported? The FAQ (the one bundled with
> the 7.1 beta3 which I'll be using) lists only:
>
> sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1

No problem for me. Solaris 7 and 8.

> If it is supported (I don't suppose a little OS version number increment
> would make a differnce here), I've never used Solaris or anything other
> than Intel-based hardware and am looking for some info on what to watch
> out for and consider when installing and tuning PostgreSQL on Solaris on
> a SPARC plattform. Aside from the shared memory stuff in the Admin
> Guide, I haven't found anything so far. Particularly, I would expect
> that you could gain a significant performance boost from running the
> database on a 64 bit plattform (without knowing exactly why, only
> picking up on word-of-mouth and assorted hype on 64 bit architectures).
> How do you get the most out of it? Would I use gcc or the native Sun
> compiler (how do you control that anyway)?

Well, maybe I'm wrong, but I guess the 64 bit push you get it compiling. I
mean, memory pages of the OS should be bigger, and the int should also be a
64 bit int, and not a 32 bit int. Maybe there is more then that, but it's all
I have to the moment.
Talking about compiler, I use gcc (compiled with the pre-compiled gcc
binaries) with the the Solaris binutils, especially because it makes life
easier.

Now, it would be a good idea to try Linux or NetBSD on the SPARC instead of
Solaris. I am at this moment getting info on the instalation of Linux distros
and the BSD distros for SPARC, and really think we can get a boost from this.

Hope this helps. ;-)

--
System Administration: It's a dirty job,
but someone told I had to do it.
-----------------------------------------------------------------
Martín Marqués email: martin(at)math(dot)unl(dot)edu(dot)ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

On Tue, Jan 23, 2001 at 06:59:16PM -0300, Martin A. Marques wrote:
[ . . . ]
> Now, it would be a good idea to try Linux or NetBSD on the SPARC instead of
> Solaris. I am at this moment getting info on the instalation of Linux distros

Not my decision, unfortunately. Otherwise I'd certainly stick with
Linux.

Regards, Frank

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(at)gmx(dot)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(at)gmx(dot)net http://yi.org/peter-e/
>
>
>

b. palmer, bpalmer(at)crimelabs(dot)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(at)gmx(dot)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(at)gmx(dot)net http://yi.org/peter-e/

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(at)gmx(dot)net http://yi.org/peter-e/

Frank Joerdens <frank(at)joerdens(dot)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

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(at)zembu(dot)com

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? (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
> > 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'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(dot)forman(at)westerngeco(dot)com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.

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

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

Frank Joerdens <frank(at)joerdens(dot)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(at)rice(dot)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(at)joerdens(dot)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(at)gmx(dot)net http://yi.org/peter-e/

Ross J. Reedstrom writes:
> Hmm, multiple processors, and lots of IPC:
> [snip]
> 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.

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(dot)forman(at)westerngeco(dot)com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.