Re: [GENERAL] pg_upgrade problem

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: depesz(at)depesz(dot)com
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [GENERAL] pg_upgrade problem
Date: 2011-09-05 21:04:32
Message-ID: 201109052104.p85L4Wx11935@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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 optimized out>) 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

Odd it is dying in the memory freeing at executor close --- not in the
ltree code.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rory Campbell-Lange 2011-09-05 21:07:54 Query runs in 335ms; function in 100,239ms : date problem?
Previous Message Ron Peterson 2011-09-05 21:01:29 Re: alter column appears to work, but doesn't?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-05 21:26:00 Re: [GENERAL] pg_upgrade problem
Previous Message Andy Colson 2011-09-05 21:03:25 Review: prepare plans of embedded sql on function start