Re: Launching debugger on self on SIGSEGV - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: Launching debugger on self on SIGSEGV
Date
Msg-id CABwTF4XeFc0wVtny0Zob0NcdS5RRESohdwk2u=JsJLM092i3Aw@mail.gmail.com
Whole thread Raw
In response to Re: Launching debugger on self on SIGSEGV  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 11, 2011 at 12:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gurjeet Singh <singh.gurjeet@gmail.com> writes:
>     The attached patch registers a signal handler for SIGSEGV and launches
> GDB in batch mode on its own pid so that the stack leading to the SEGV can
> be dumped in the server logs.

Did you not read the thread last week about how we did not want any such
thing?

Unfortunately, I did not. I'll catch up on it.
 
Quite aside from any postgres-specific reasons not to have any added
delay in the signal-to-database-shutdown path, this patch makes a bunch
of untenable assumptions about whether or where gdb is installed,
whether there are usable debug symbols available, whether gdb's output
will go somewhere useful, etc etc.  And on top of all that, it adds *no
functionality whatsoever* compared to a post-mortem gdb run on the core
file.

I agree that it makes a bunch of assumptions, that's why I proposed that we make it user configurable parameter, like archive_command, so that users (or their packagers) can provide the command and all the relevant options.

Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Full GUID support
Next
From: Patrick Earl
Date:
Subject: Re: Full GUID support