From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Strange failure on mamba |
Date: | 2022-11-18 03:25:23 |
Message-ID: | 20221118032523.26t4njvrqijapxff@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-11-17 17:47:50 -0500, Tom Lane wrote:
> Yeah, that or some other NetBSD bug could be the explanation, too.
> Without a stack trace it's hard to have any confidence about it,
> but I've been unable to reproduce the problem outside the buildfarm.
> (Which is a familiar refrain. I wonder what it is about the buildfarm
> environment that makes it act different from the exact same code running
> on the exact same machine.)
>
> So I'd like to have some way to make the postmaster send SIGABRT instead
> of SIGKILL in the buildfarm environment. The lowest-tech way would be
> to drive that off some #define or other. We could scale it up to a GUC
> perhaps. Adjacent to that, I also wonder whether SIGABRT wouldn't be
> more useful than SIGSTOP for the existing SendStop half-a-feature ---
> the idea that people should collect cores manually seems mighty
> last-century.
I suspect that having a GUC would be a good idea. I needed something similar
recently, debugging an occasional hang in the AIO patchset. I first tried
something like your #define approach and it did cause a problematic flood of
core files.
I ended up using libbacktrace to generate useful backtraces (vs what
backtrace_symbols() generates) when receiving SIGQUIT. I didn't do the legwork
to make it properly signal safe, but it'd be doable afaiu.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-11-18 03:55:14 | Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes |
Previous Message | Andres Freund | 2022-11-18 03:03:25 | Re: logical decoding and replication of sequences, take 2 |