Re: Postgres with pthread

On 7 December 2017 at 19:55, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
wrote:

>
> Pros:
> 1. Simplified memory model: no need in DSM, shm_mq, DSA, etc
>

shm_mq would remain useful, and the others could only be dropped if you
also dropped process-model support entirely.

> 1. Breaks compatibility with existed extensions and adds more requirements
> for authors of new extension
>

Depends on how much frightening preprocessor magic you're willing to use,
doesn't it? ;)

Wouldn't be surprised if simple extensions (C functions etc) stayed fairly
happy, but it'd be hazardous enough in terms of library use etc that
deliberate breakage may be beter.

> 2. Problems with integration of single-threaded PLs: Python, Lua,...
>

Yeah, that's going to hurt. Especially since most non-plpgsql code out
there will be plperl and plpython. Breaking that's not going to be an
option, but nobody's going to be happy if all postgres backends must
contend for the same Python GIL. Plus it'd be deadlock-city.

That's nearly a showstopper right there. Especially since with a quick look
around it looks like the cPython GIL is per-DLL (at least on Windows) not
per-interpreter-state, so spawning separate interpreter states per-thread
may not be sufficient. That makes sense given that cPython its self is
thread-aware; otherwise it'd have a really hard time figuring out which GIL
and interpreter state to look at when in a cPython-spawned thread.

> 3. Worser protection from programming errors, included errors in
> extensions.
>

Mainly contaminating memory of unrelated procesess, or the postmaster.

I'm not worried about outright crashes. On any modern system it's not
significantly worse to take down the postmaster than it is to have it do
its own recovery. A modern init will restart it promptly. (If you're not
running postgres under an init daemon for production then... well, you
should be.)

> 4. Lack of explicit separation of shared and privite memory leads to more
> synchronization errors.
>

Accidentally clobbering postmaster memory/state would be my main worry
there.

Right now we gain a lot of protection from our copy-on-write
shared-nothing-by-default model, and we rely on it in quite a lot of places
where backends merrily stomp on inherited postmaster state.

The more I think about it, the less enthusiastic I am, really.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services