On Tue, Jun 29, 2010 at 9:34 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Kelly Burkhart <kelly.burkhart@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
