Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi,

On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote:
> On 19/07/18 03:26, Asim R P wrote:
> > On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > >
> > > Or, probably more robust: Simply _exit(2) without further ado, and rely
> > > on postmaster to output an appropriate error message. Arguably it's not
> > > actually useful to see hundreds of "WARNING: terminating connection because of
> > > crash of another server process" messages in the log anyway.
> > >
> >
> > To support using _exit(2) in *quickdie() handlers, I would like to
> > share another stack trace indicating self-deadlock. In this case, WAL
> > writer process got SIGQUIT while it was already handling a SIGQUIT,
> > leading to self-deadlock.
>
> Ugh. Yeah, in wal_quickdie, and other aux process *_quickdie() handlers, I
> agree we should just _exit(2). All we want to do is to exit the process
> immediately.

Indeed.

> bgworker_quickdie() makes some effort to block SIGQUIT during the exit()
> processing, but that doesn't solve the whole problem. The process could've
> been in the middle of a malloc/free when the signal arrived, for example.
> exit() is simply not safe to call from a signal handler.

Yea. I really don't understand why we have't been able to agree on this
for *years* now.

> The regular backend's quickdie() function is more tricky. It should also
> call _exit(2) rather than exit(2). But it also tries to ereport a WARNING,
> and that is quite useful.

Is that actually true? Clients like libpq create the same error message
(which has its own issues, because it'll sometimes mis-interpret
things). The message doesn't actually have useful content, no?

Greetings,

Andres Freund