Our new Server is a sun T2000 with the "CoolThreads" technology.
Wi installed the recomended gcc version to take advantage of the new features of this technology:

Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /net/clpt-v490-1/export/data/bldmstr/20070425_mars_gcc/src/configure --prefix=/usr/sfw --enable -shared --with-system-zlib --enable-checking=release --disable-libmudflap --enable-languages=c,c++ --enable-vers ion-specific-runtime-libs --with-cpu=v9 --with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.0.4 (gccfss)

Here is the pg_config output:

BINDIR = /usr/bin
DOCDIR = /usr/share/doc/pgsql/8.1.4
INCLUDEDIR = /usr/include/pgsql
PKGINCLUDEDIR = /usr/include/pgsql
INCLUDEDIR-SERVER = /usr/include/pgsql/server
LIBDIR = /usr/lib
PKGLIBDIR = /usr/lib
LOCALEDIR = /usr/share/locale
MANDIR = /usr/share/man
SHAREDIR = /usr/share/pgsql
SYSCONFDIR = /etc/pgsql
PGXS = /usr/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--prefix=/usr' '--bindir=/usr/bin' '--libexecdir=/usr/bin' '--sbindir=/usr/bin' '--datadir=/usr/share/pgsql' '--sysconfdir=/etc/pgsql' '--mandir=/usr/share/man' '--libdir=/usr/lib' '--includedir=/usr/include/pgsql' '--sharedstatedir=/var/lib/pgsql' '--localstatedir=/var/lib/pgsql' '--enable-nls' '--with-localedir=/usr/share/locale' '--with-docdir=/usr/share/doc/pgsql/8.1.4' '--with-tcl' '--with-perl' '--with-python' '--with-pam' '--with-openssl' '--enable-thread-safety' '--with-includes=/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/include:/usr/sfw/include' '--with-tclconfig=/usr/sfw/lib' '--with-libs=/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/lib:/usr/sfw/lib:/usr/lib' 'CC=/ws/on10-tools/SUNWspro/SOS8/bin/cc' 'CFLAGS=-xc99=none -xCC'
CC = /ws/on10-tools/SUNWspro/SOS8/bin/cc
CPPFLAGS = -I/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/include -I/usr/sfw/include
CFLAGS = -xO3 -xarch=v8 -xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff -xc99=none -xCC
CFLAGS_SL = -KPIC
LDFLAGS = -L/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/lib -L/usr/sfw/lib -L/usr/lib -Wl,-R/usr/lib
LDFLAGS_SL =
LIBS = -lpgport -lpam -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lresolv -lgen -lsocket -lnsl -ldl -lm
VERSION = PostgreSQL 8.1.4

Now I'm going to recompile using a 3.4.3 version to see what happens...

En/na Tom Lane ha escrit:

Daniel Rubio <drubior@tinet.org> writes:

Here's the stack trace, I'm not sure this is all you need (it's the 
first time I use gdb) so, tell me if you need more information

Core was generated by `/aplicacions/postgres/bin/postmaster -D 
/aplicacions/postgres/data'.
Program terminated with signal 11, Segmentation fault.
#0  0x001a66b4 in HaveNFreeProcs ()
(gdb) backtrace
#0  0x001a66b4 in HaveNFreeProcs ()
#1  0x0024deb4 in InitPostgres ()
#2  0x001b1464 in PostgresMain ()
#3  0x001837f0 in ServerLoop ()
#4  0x00184cd8 in PostmasterMain ()
#5  0x001373f8 in main ()


Well, that's pretty darn odd.  It looks like you could work around the
crash by setting superuser_reserved_connections to 0, but that doesn't
tell us *why* it's crashing.  HaveNFreeProcs, and the data structure
it looks at, are simple enough that it's hard to credit a bug there.
I'm worried that what you've got is really a compiler bug.  What
compiler did you build with, and did you use any nondefault CFLAGS?
(pg_config output would be helpful here.)

			regards, tom lane

-- 
********************************************************
Daniel Rubio Rodríguez
OASI (Organisme Autònom Per la Societat de la Informació)
c/ Assalt, 12
43003 - Tarragona
Tef.: 977.244.007 - Fax: 977.224.517
e-mail: drubio a oasi.org
********************************************************