Re: Backend Crash v8.4.2

From: Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Backend Crash v8.4.2
Date: 2010-06-30 17:34:57
Message-ID: AANLkTikfxzfsjpHIbpuau7nnjADW38GOavvRy2FsEOqo@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 30, 2010 at 11:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Best guess from here is that you managed to run into some sort of
> cache-reload bug; those are very sensitive to concurrent operations
> since you only see them when a shared cache inval event happens at
> just the wrong time.  I would recommend an update to 8.4.4 since we
> did stomp two or three critters of that ilk in the last few months,
> but I can't really guarantee that we found the one that bit you.
>
> While you're at it, please try to make sure you install a non-symbol-
> stripped version of 8.4.4.  If it does happen again, at least you'll
> be prepared to collect more data.
>

We'll plan on upgrading.

RE: stripped symbols, I assume you mean configuring with
--enable-debug specified, I see from my config.log that I did not
specify that flag. I just built with debug symbols on a
non-production machine and the stack trace is different. I assume
it's completely invalid because symbol addresses from different builds
are not guaranteed to line up. Correct? Or is this helpful?

Program terminated with signal 11, Segmentation fault.
#0 0x000000000068d884 in RelationCacheInitializePhase2 () at relcache.c:2588
2588 LOAD_CRIT_INDEX(IndexRelidIndexId);
(gdb) where
#0 0x000000000068d884 in RelationCacheInitializePhase2 () at relcache.c:2588
#1 0x0000000000000000 in ?? ()
(gdb)

Thanks,

-K

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Grey 2010-06-30 17:56:06 Re: dropdb weirdness
Previous Message Tim Landscheidt 2010-06-30 17:18:08 Re: Filtering by tags