From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Backend Crash v8.4.2 |
Date: | 2010-06-29 14:34:57 |
Message-ID: | 18200.1277822097@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)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.
> 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
If that just gives you a number and not the text of a SQL query, try
p (char *) debug_query_string
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2010-06-29 14:39:40 | Re: Fwd: Re: Weird trouble with select |
Previous Message | Jacqui Caren-home | 2010-06-29 14:30:34 | Re: Migrating from MySQL |