* Martijn van Oosterhout:
>> The fact remains that the postmaster has *always* been coded like that,
>> and we have *never* seen any problems. Barring proof that there is a
>> problem, I'm uninterested in rewriting it just because someone doesn't
>> like it.
>
> It should probably also be remembe
On Thu, May 11, 2006 at 10:11:00AM -0400, Tom Lane wrote:
> Douglas McNaught <[EMAIL PROTECTED]> writes:
> > I don't disagree with your reasoning, but does POSIX actually say
> > this?
>
> The fact remains that the postmaster has *always* been coded like that,
> and we have *never* seen any proble
Douglas McNaught <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
>> Running unsafe functions within a signal handler is not unsafe per-se.
>> It's only unsafe if the main program could also be running unsafe
>> functions.
> I don't disagree with your reasoning, but does POSIX actuall
On Thu, May 11, 2006 at 08:24:02AM -0400, Douglas McNaught wrote:
> Martijn van Oosterhout writes:
>
> > Running unsafe functions within a signal handler is not unsafe per-se.
> > It's only unsafe if the main program could also be running unsafe
> > functions.
>
> I don't disagree with your reas
Martijn van Oosterhout writes:
> Running unsafe functions within a signal handler is not unsafe per-se.
> It's only unsafe if the main program could also be running unsafe
> functions.
I don't disagree with your reasoning, but does POSIX actually say
this?
-Doug
---(end
On Thu, May 11, 2006 at 01:59:46PM +0200, Zdenek Kotala wrote:
> Decision is that Postgres uses signal dangerous functions (fopen, ...)
> and its signal handler is not save and should generate unpredictable
> behavior after signal processing. I would like to fix it, but there is
> some waiting p
Alvaro Herrera wrote:
Zdenek Kotala wrote:
I performed some investigation and I found that signal handler
(SIGHUP_handler) contents a big code and contents signal nonsafe
functions. It should generate deadlock or damage some internal data
structure in the standard c library. See
h
