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

On 2018-07-19 15:17:26 -0500, Nico Williams wrote:
> On Thu, Jul 19, 2018 at 01:10:14PM -0700, Andres Freund wrote:
> > On 2018-07-19 15:04:15 -0500, Nico Williams wrote:
> > > 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).
> >
> > It'd also increase memory usage noticably (we'd have twice the process
> > count in the kernel, would have a lot of additional stacks etc), would
> > tie us to supporting threading in the backend, ... This is a DOA
> > approach imo.
>
> You can create that thread with a really small stack given that its only
> purpose is to do this error reporting and exit.

You still have a full kernel process backing it, which is *FAR* from
free. And we'd enough infrastructure to setup threads with small stacks
on a number of platforms.

> Running a thread that does only this does not impact the rest of the
> code in the backend at all -- it's not "threading" the backend.

It actually does. Without passing thread related flags to the compiler,
which you need to do for correctness, the compiler and libraries are
free to use faster non-threadsafe implementations.

Greetings,

Andres Freund