Re: We shouldn't signal process groups with SIGQUIT - Mailing list pgsql-hackers

From Andres Freund
Subject Re: We shouldn't signal process groups with SIGQUIT
Date
Msg-id 20230215002059.aovvewsai3wehi4z@awork3.anarazel.de
Whole thread Raw
In response to Re: We shouldn't signal process groups with SIGQUIT  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: We shouldn't signal process groups with SIGQUIT
List pgsql-hackers
Hi,

On 2023-02-14 14:23:32 -0800, Nathan Bossart wrote:
> On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> > Not really related: I do wonder how often we end up self deadlocking in
> > quickdie(), due to the ereport() not beeing reentrant. We'll "fix" it soon
> > after, due to postmasters SIGKILL.  Perhaps we should turn on
> > send_abort_for_kill on CI?
> 
> +1, this seems like it'd be useful in general.  I'm guessing this will
> require a bit of work on the CI side to generate the backtrace.

They're already generated for all current platforms.  It's possible that debug
info for some system libraries is missing, but the most important one (like
libc) should be available.

Since yesterday the cfbot website allows to easily find the coredumps, too:
http://cfbot.cputube.org/highlights/core-7.html

There's definitely some work to be done to make the contents of the backtraces
more useful though.  E.g. printing out the program name, the current directory
(although that doesn't seem to be doable for all programs). For everything but
windows that's in src/tools/ci/cores_backtrace.sh.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: [PATCH] Add pretty-printed XML output option
Next
From: Andres Freund
Date:
Subject: Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?