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

From: Nico Williams <nico(at)cryptonector(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jimmy Yih <jyih(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket
Date: 2018-07-19 20:04:15
Message-ID: 20180719200414.GK9712@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 22, 2017 at 03:10:31PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > 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.
>
> At that point you might as well skip the entire mechanism and go straight
> to SIGKILL. IMO the only reason quickdie() exists at all is to try to
> send a helpful message to the client. And it is helpful --- your attempt
> to claim that it isn't sounds very much like wishful thinking.

I dunno if it is or isn't helpful. But I do know that this must be done
in an async-signal-safe way.

Besides making ereport() async-signal-safe, which is tricky, you could
write(2) the arguments to a pipe that another thread in the same process
is reading from and which will then call ereport() and exit(3). This
would be less work if you're willing to use a thread for that (the
thread would only block in read(2) on that pipe, and would only provide
this one service).

Nico
--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2018-07-19 20:07:28 Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket
Previous Message Tom Lane 2018-07-19 20:04:01 Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket