Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> Tom Lane wrote:
>> 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.
> It is very common that you either get a null pointer exception (attempt
> to access address zero), that your stack will hit a write protected page
> (stack overflow), or that you get some sort of arithemtic exception.
> These conditions can be trapped and gracefully handled.
That argument has zilch to do with the question at hand. If you use a
coding style in which these things should be considered recoverable
errors, then setting up a signal handler to recover from them works
about the same whether the process is multi-threaded or not. The point
I was trying to make is that when an unrecognized trap occurs, you have
to assume not only that the current thread of execution is a lost cause,
but that it may have clobbered any memory it can get its hands on.
> I'm not sure I follow. You will be able to bring all threads of one
> process to a halt much faster than you can kill a number of external
Speed is not even a factor in this discussion; or do you habitually
spend time optimizing cases that aren't supposed to happen? The point
here is circumscribing how much can go wrong before you realize you're
regards, tom lane
In response to
pgsql-general by date
|Next:||From: Ed L.||Date: 2004-10-27 23:01:45|
|Subject: WARNING: column "footype" has type "unknown"|
|Previous:||From: Michael Fuhr||Date: 2004-10-27 22:52:28|
|Subject: Re: interval to seconds conversion. How?|