Martijn van Oosterhout <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html