Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
| От | Craig Ringer |
|---|---|
| Тема | Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme |
| Дата | |
| Msg-id | 4CF0CE16.90402@postnewspapers.com.au обсуждение исходный текст |
| Ответ на | BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme ("Bala Murugan" <b2m@a-cti.com>) |
| Список | pgsql-bugs |
On 27/11/2010 5:09 PM, Balamurugan Mahendran wrote: > Program received signal SIGQUIT, Quit. That's a signal 3 (SIGQUIT). You said you were getting signal 11 (SIGSEGV) crashes. Are you sure this is the same thing? I suspect you've connected to one of the other backends, not the backend that actually crashes. You need to identify which one gets the SIGSEGV. It may be a short-lived autovacuum worker, in which case you'll have a hard time getting gdb attached to it before it goes splat. If you do manage to get gdb connected to the crashing backend, instead of just continuing after gdb pauses at the fatal signal (SIGSEGV), type at the (gdb) prompt: bt then press enter. You may instead want to enable core dumps as per the instructions on the same page: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD ... then run gdb on the core dump after the crash. That can potentially be easier if the crashing backend isn't the one doing the COPY. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
В списке pgsql-bugs по дате отправления: