Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket - Mailing list pgsql-hackers

From Nico Williams
Subject Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Date
Msg-id 20180719203810.GO9712@localhost
Whole thread Raw
In response to Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Jul 19, 2018 at 01:35:02PM -0700, Andres Freund wrote:
> On 2018-07-19 15:17:26 -0500, Nico Williams wrote:
> > 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. [...]

It's not that big.  Its stack is small.
> [...] And we'd enough infrastructure to setup threads with small stacks
> on a number of platforms.

Portability is actually the problem here, yes.  But you could enable the
async-signal-safe thread path in some platforms and not others, and
you'd still be improving things.

> > 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.

That's build goop, but there's no need to add mutexes or whatever
elsewhere.

Nico
-- 


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket