Subject: Re: SIGQUIT handling, redux

From: Andres Freund <[email-masked]>
Date: Wed, 2 Aug 2023 09:25:50 -0700

Hi,

On 2020-09-11 11:52:55 -0400, Tom Lane wrote:
> It's simple enough that maybe we could back-patch it, once it's
> aged awhile in HEAD.  OTOH, given the lack of field reports of
> trouble here, I'm not sure back-patching is worth the risk.

FWIW, looking at collected stack traces in azure, there's a slow but steady
stream of crashes below StartupPacketTimeoutHandler. Most seem to be things
like
libcrypto->malloc->StartupPacketTimeoutHandler->proc_exit->socket_close->free->crash
there's a few other variants, some where the stack apparently was not
decipherable for the relevant tooling.

Note that this wouldn't even include cases where this caused hangs - which is
quite common IME.

Unsurprisingly just in versions before 14, where this change went in.

I think that might be enough evidence for backpatching the commit? I've not
heard of issues due to the checks in check_on_shmem_exit_lists_are_empty().

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Wed, 02 Aug 2023 12:35:19 -0400

> stream of crashes below StartupPacketTimeoutHandler. ...

I'd be willing to take a look at this in a few weeks when $real_life
is a bit less demanding.  Right before minor releases would likely be
a bad idea anyway.

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Wed, 2 Aug 2023 09:48:40 -0700

Hi,

On 2023-08-02 12:35:19 -0400, Tom Lane wrote:
> is a bit less demanding.

Cool.

> Right before minor releases would likely be a bad idea anyway.

Agreed. I had just waded through the stacks, so I thought it'd be worth
bringing up, didn't intend to imply we should backpatch immediately.

Aside: Analyzing this kind of thing at scale is made considerably more painful
by "expected" ereport(PANIC)s (say out of disk space during WAL writes)
calling abort() and dumping core... While there are other PANICs you really
want cores of.

Greetings,

Andres Freund