On Tue, Jun 29, 2010 at 9:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kelly Burkhart <kelly.burkhart@gmail.com> writes:
>> The crash left a core file, does the stack trace indicate anything crucial?
>
>> (gdb) where
>> #0 0x000000000068d884 in SearchCatCacheList ()
>> #1 0x0000000100000000 in ?? ()
>> #2 0x0000000000bbcbe0 in ?? ()
>> #3 0x00007f3b3a86a580 in ?? ()
>> #4 0x72ddbea20068dae0 in ?? ()
>> #5 0x00007fff78faa720 in ?? ()
>> #6 0x0000000000000000 in ?? ()
>> Current language: auto
>> The current source language is "auto; currently asm".
>
> That's pretty much useless unless you can install debug symbols and
> try again. I will say though that this is probably a new bug ---
> I don't recall seeing anything crashing in SearchCatCacheList recently.
I had our system people install the debug symbols and I get the same
stack trace. I believe the symbols are indeed installed, yesterday
when I started gdb I saw a bunch of lines like this:
Missing separate debuginfo for /usr/lib64/libssl.so.0.9.8
Try: zypper install -C
"debuginfo(build-id)=c1d9e2a7e013149b5acc4d3580724d4827f5827c"
I don't see that now.
>
>> Can anyone provide some guidance on how I can go about discovering the
>> cause?
>
> Please try to create a reproducible test case. One thing you can get to
> start from is the query that was being executed --- try this in gdb:
>
> p debug_query_string
I was able to see the query:
select sd.close, s.minimum_trade_increment
from symbol_daily sd, symbol s
where s.symbol_name = sd.symbol_name
and s.exchange_name = sd.exchange_name
and sd.symbol_name = $1
and sd.trading_dt = last_trading_dt()
It's a well established query done probably several times each
morning. I don't know how to create a reproducible test case as I
can't determine anything that we did yesterday that was any different
from any other day.
-K