Обсуждение: Can't login to 8.2.4 if not superuser...
Hi all
I'm experiencing a weird situation with my test installation for 8.2.4.
I installed with no problems on Solaris 10, and I've imported my
databases and users from a 7.4.14 using the 8.2.4 pg_dumpall without
excessive problems (some things about permissions on some tables, but I
think it's not related).
If I log via psql using the postgres user via psql there's no problem,
but If I try to log as a different user, the postmaster process hangs
and I can't connect.
On the log file (debug1, using syslog) I see:
Sep 5 09:24:10 pluto2 pg[7698]: [ID 748848 local4.info] [14-1] LOG:
connection received: host=[local]
Sep 5 09:24:10 pluto2 pg[7698]: [ID 748848 local4.info] [15-1] LOG:
connection authorized: user=xxx database=xxx
Sep 5 09:24:21 pluto2 pg[833]: [ID 748848 local4.info] [14-1] LOG:
server process (PID 7698) was terminated by signal 11
Sep 5 09:24:21 pluto2 pg[833]: [ID 748848 local4.info] [15-1] LOG:
terminating any other active server processes
Sep 5 09:24:21 pluto2 pg[833]: [ID 748848 local4.info] [16-1] LOG: all
server processes terminated; reinitializing
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [17-1] LOG:
database system was interrupted at 2007-09-05 09:08:10 CEST
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [18-1] LOG:
checkpoint record is at 0/2CFCB380
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [19-1] LOG:
redo record is at 0/2CFCB380; undo record is at 0/0; shutdown TRUE
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [20-1] LOG:
next transaction ID: 0/2662; next OID: 917504
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [21-1] LOG:
next MultiXactId: 1; next MultiXactOffset: 0
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [22-1] LOG:
database system was not properly shut down; automatic recovery in progress
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [23-1] LOG:
record with zero length at 0/2CFCB3D0
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [24-1] LOG:
redo is not required
Sep 5 09:24:21 pluto2 pg[7700]: [ID 748848 local4.info] [25-1] LOG:
database system is ready
And in the command line:
bash-3.00# ../bin/psql -d xxx -U xxx
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
If I login with the postgres user there's no problem, and if I set the
user xxx as superuser (using pgAdmin) I can login with it too ...
Actually, for test purposes, my pg_hba.conf settings are:
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1 255.255.255.255 password
host all all xxx.xxx.xxx.xxx 255.255.255.255 password
host all all yyy.yyy.yyy.yyy 255.255.255.255 password
Where xxx.xxx.xxx.xxx is my host public ip address and yyy.yyy.yyy.yyy
my laptop IP to access with pgAdmin.
Some idea about what it's happening?
--
********************************************************
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
********************************************************
Daniel Rubio <drubior@tinet.org> writes:
> If I log via psql using the postgres user via psql there's no problem,
> but If I try to log as a different user, the postmaster process hangs
> and I can't connect.
That's not a hang, it's a core dump. Can you get a stack trace with
gdb or local equivalent?
regards, tom lane
En/na Tom Lane ha escrit: > That's not a hang, it's a core dump. Can you get a stack trace with > gdb or local equivalent? > 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 () > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > > > > -- ******************************************************** 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 ********************************************************
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
Our new Server is a sun T2000 with the "CoolThreads" technology.<br /> Wi installed the recomended gcc version to take
advantageof the new features of this technology:<br /><br /> Using built-in specs.<br /> Target:
sparc-sun-solaris2.10<br/> 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<br /> Thread model: posix<br /> gcc
version4.0.4 (gccfss)<br /><br /> Here is the pg_config output:<br /><br /> BINDIR = /usr/bin<br /> DOCDIR =
/usr/share/doc/pgsql/8.1.4<br/> INCLUDEDIR = /usr/include/pgsql<br /> PKGINCLUDEDIR = /usr/include/pgsql<br />
INCLUDEDIR-SERVER= /usr/include/pgsql/server<br /> LIBDIR = /usr/lib<br /> PKGLIBDIR = /usr/lib<br /> LOCALEDIR =
/usr/share/locale<br/> MANDIR = /usr/share/man<br /> SHAREDIR = /usr/share/pgsql<br /> SYSCONFDIR = /etc/pgsql<br />
PGXS= /usr/lib/pgxs/src/makefiles/pgxs.mk<br /> 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'<br /> CC = /ws/on10-tools/SUNWspro/SOS8/bin/cc<br />
CPPFLAGS= -I/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/include -I/usr/sfw/include<br /> CFLAGS = -xO3
-xarch=v8-xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff -xc99=none -xCC<br /> CFLAGS_SL = -KPIC<br /> LDFLAGS =
-L/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/lib-L/usr/sfw/lib -L/usr/lib -Wl,-R/usr/lib<br />
LDFLAGS_SL=<br /> LIBS = -lpgport -lpam -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lresolv -lgen -lsocket -lnsl -ldl
-lm<br/> VERSION = PostgreSQL 8.1.4<br /><br /> Now I'm going to recompile using a 3.4.3 version to see what
happens...<br/><br /><br /> En/na Tom Lane ha escrit: <blockquote cite="mid:22268.1189088283@sss.pgh.pa.us"
type="cite"><prewrap="">Daniel Rubio <a class="moz-txt-link-rfc2396E"
href="mailto:drubior@tinet.org"><drubior@tinet.org></a>writes: </pre><blockquote type="cite"><pre wrap="">Here's
thestack 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 </pre></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">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 () </pre></blockquote><pre wrap="">
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
</pre></blockquote><br /><br /><pre class="moz-signature" cols="72">--
********************************************************
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
******************************************************** </pre>
Using the older gcc version to compile, the problem disappears ... En/na Daniel Rubio ha escrit: > 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 > ******************************************************** > > -- ******************************************************** 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 ********************************************************
Daniel Rubio <drubior@tinet.org> writes:
> Using the older gcc version to compile, the problem disappears ...
Hmm. gcc 4.0.4 is hardly new. I'm wondering about the weird CFLAGS and
include/link paths shown in your pg_config output. What does all that
do?
>> 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
>> LDFLAGS = -L/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/lib
>> -L/usr/sfw/lib -L/usr/lib -Wl,-R/usr/lib
regards, tom lane
On 9/7/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Rubio <drubior@tinet.org> writes: > > Using the older gcc version to compile, the problem disappears ... > > Hmm. gcc 4.0.4 is hardly new. I'm wondering about the weird CFLAGS and > include/link paths shown in your pg_config output. What does all that > do? > > >> CPPFLAGS = -I/sfw10/builds/build/sfw10-patch/usr/src/cmd/postgres/rltmp/include > >> -I/usr/sfw/include > >> CFLAGS = -xO3 isn't that an Optimization setting? Pretty sure pgsql is not recommended above 2. or is -xO something different? OP, Have you tried compiling with just the bare minimum switches to get a working version and go from there?