Re: [GENERAL] pg_upgrade problem - Mailing list pgsql-hackers

From hubert depesz lubaczewski
Subject Re: [GENERAL] pg_upgrade problem
Date
Msg-id 20110905204627.GA23389@depesz.com
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade problem  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [GENERAL] pg_upgrade problem
List pgsql-hackers
On Mon, Sep 05, 2011 at 04:43:47PM -0400, Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
> > > hubert depesz lubaczewski wrote:
> > > > On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > > > > hubert depesz lubaczewski wrote:
> > > > > > I'm not sure if it's upgrade thing, or is it because of error in
> > > > > > ltree/compilation, but it looks bad.
> > > > > > 
> > > > > > Is there any more info I could show/gather to help debug the issue?
> > > > > 
> > > > > I am confused by the error --- is it not loading, or can you get a
> > > > > backtrace of the crash?
> > > > 
> > > > The one in logs is not sufficient?
> > > > If not - could you tell me how to make the backtrace? I'm by far not a c
> > > > programmer, so for this I'd need some tutoring.
> > > 
> > > I think you want this:
> > > 
> > >     http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
> > > 
> > > While strace is useful, it doesn't show us where the C code is failing.
> > 
> > ok.
> > got this:
> > 
> > (gdb) bt
> > #0  0x00007fdc28605095 in raise () from /lib/libc.so.6
> > #1  0x00007fdc28606af0 in abort () from /lib/libc.so.6
> > #2  0x00007fdc2863fa7b in ?? () from /lib/libc.so.6
> > #3  0x00007fdc2864708a in ?? () from /lib/libc.so.6
> > #4  0x00007fdc2864ac1c in free () from /lib/libc.so.6
> > #5  0x00000000006c18c9 in AllocSetDelete (context=<value optimized out>) at aset.c:551
> > #6  0x00000000006c1e54 in MemoryContextDelete (context=0xbdae80) at mcxt.c:196
> > #7  0x000000000054913e in standard_ExecutorEnd (queryDesc=0xbbb4f0) at execMain.c:360
> > #8  0x000000000051c88f in PortalCleanup (portal=0xbb7a70) at portalcmds.c:268
> > #9  0x00000000006c26fc in PortalDrop (portal=0xbb7a70, isTopCommit=0 '\0') at portalmem.c:434
> > #10 0x00000000005f8c95 in exec_simple_query (query_string=0xb9b980 "select * from categories limit 1;") at
postgres.c:1067
> > #11 0x00000000005f95de in PostgresMain (argc=<value optimized out>, argv=<value optimized out>, username=<value
optimizedout>) at postgres.c:3936
 
> > #12 0x00000000005c94f6 in ServerLoop () at postmaster.c:3555
> > #13 0x00000000005ca0fe in PostmasterMain (argc=3, argv=0xaf0870) at postmaster.c:1092
> > #14 0x0000000000574070 in main (argc=3, argv=0xaf0870) at main.c:188
> 
> Good.  Is it possible to compile with debug symbols, -g?  Odd you are
> crashing in libc.

this had debug:

./configure \       --prefix=/opt/pgsql-9.0.5a-int \       --enable-debug \       --disable-rpath \
--without-perl\       --without-python \       --without-tcl \       --without-openssl \       --without-pam \
--without-krb5\       --without-gssapi \       --enable-nls \       --enable-integer-datetimes \
--enable-thread-safety\       --with-libxml \       --with-libxslt \       --without-ldap
 

Best regards,

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                  http://depesz.com/
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] pg_upgrade problem
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] pg_upgrade problem