That’s not true for Postgres however: due to its usage of a shared memory pool, whenever a subprocess is terminated unexpectedly, Postgres will kill all other processes and enter recovery mode, replaying the WAL, during which time it will not accept connection requests.

It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.

If it's a choice between performance and being able to "safely" run sketchy extensions, I'd rather have performance.

Doesn't postgres (rightly) have a cow if a process has a disorderly shutdown (at least while in a write transaction) because there's shared memory between the processes?

Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested."

Clearly a process per connection is more stable and that's what I'm using.

It's unclear what problem such optimizations are solving anyway, with the old way you could only support a million concurrent users with a single server? Are we missing out on supporting ten million concurrent users with 2 servers instead of 10? Ostensibly reducing the minimum db hardware opex for a 10B$ company from 10k$/month to 2k$/month?

Is that a serious issue? Wouldn't it just restart the split second later? Or does it take a long time to start?

(Or I guess it would get stuck in a doom loop or something?)

I'm not informed of the Postgres's internals, but, maybe, that can be solved by grouping threads into different processes depending on which set of extensions they request.

A more modern way to do this might be to support WebAssembly plugins.

The extensions might need to be rewritten, but hey, we have AI for that now, so why not :-)

An OS thread per connection can be fine for performance if you don't have to scale your connections, but if you don't need to scale connections why have connections at all? Databases are even more performant when you eliminate connection overhead entirely.