Re: Backend Crash v8.4.2
От | Kelly Burkhart |
---|---|
Тема | Re: Backend Crash v8.4.2 |
Дата | |
Msg-id | AANLkTikfxzfsjpHIbpuau7nnjADW38GOavvRy2FsEOqo@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Backend Crash v8.4.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Backend Crash v8.4.2
|
Список | pgsql-general |
On Wed, Jun 30, 2010 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-general по дате отправления: