Re: Reasoning behind process instead of thread based

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> ... Signals are shared between threads. Now, you could ofcourse catch
> these signals but you only have one address space shared between all
> the threads, so if you want to exit to get a new process image (because
> something is corrupted), you have to close all connections.

Right. Depending on your OS you may be able to catch a signal that
would kill a thread and keep it from killing the whole process, but
this still leaves you with a process memory space that may or may not
be corrupted. Continuing in that situation is not cool, at least not
according to the Postgres project's notions of reliable software design.

It should be pointed out that when we get a hard backend crash, Postgres
will forcibly terminate all the backends and reinitialize; which means
that in terms of letting concurrent sessions keep going, we are not any
more forgiving than a single-address-space multithreaded server. The
real bottom line here is that we have good prospects of confining the
damage done by the failed process: it's unlikely that anything bad will
happen to already-committed data on disk or that any other sessions will
return wrong answers to their clients before we are able to kill them.
It'd be a lot harder to say that with any assurance for a multithreaded
server.

regards, tom lane