Re: Reasoning behind process instead of thread based - Mailing list pgsql-general

From Chris Browne
Subject Re: Reasoning behind process instead of thread based
Date
Msg-id 60k6t9par9.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Reasoning behind process instead of thread based arch?  (nd02tsk@student.hig.se)
List pgsql-general
nd02tsk@student.hig.se writes:
>>Two:  If a
>> single process in a multi-process application crashes, that process
>> alone dies.  The buffer is flushed, and all the other child processes
>> continue happily along.  In a multi-threaded environment, when one
>> thread dies, they all die.
>
> So this means that if a single connection thread dies in MySQL, all
> connections die?

Yes, that's right.

> Seems rather serious. I am doubtful that is how they have
> implemented it.

If it's a multithreaded application, then there is nothing to doubt
about the matter.  If any thread dies, the whole process croaks, and
there's no choice in the matter.  If a thread has been corrupted to
the point of crashing, then the entire process has been corrupted.
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxxian.html
A VAX is virtually a computer, but not quite.

pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Recommended Procedure for Archiving Table Data
Next
From: Chris Browne
Date:
Subject: Re: The reasoning behind having several features outside of source?