Re: Removing dead support for pre-POSIX signals - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing dead support for pre-POSIX signals
Date
Msg-id 29255.1440963662@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing dead support for pre-POSIX signals  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-08-30 15:28:42 -0400, Tom Lane wrote:
>> No no no, I'm proposing to remove the above-quoted lines and the configure
>> test.  sig_atomic_t is required by C89; there is no reason anymore to
>> cope with it not being provided by <signal.h>.

> Ok, that works for me. You seemed to be a bit more doubtful about the
> sig_atomic_t support, that's why I thought you might want to do
> something but rip it out. Seems like a pretty low risk thing to try.

The distinction I was making was that it's fair to suspect that the
pre-POSIX-signal code is actively broken.  (For instance, as far back as
commit 8408f6525 we were aware that libpq's thread-safe signal logic would
not work with pre-POSIX signals.  How many other cases do you think have
snuck in unnoticed since then?)  On the other hand, there's no reason to
think that the substitute sig_atomic_t typedef wouldn't work fine if it
were used.  The argument for ripping that out is merely that it's silly to
continue expending configure cycles on something that's required by C89.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Horizontal scalability/sharding
Next
From: Christoph Berg
Date:
Subject: Re: datestyle=postgres broken with timezone=UTC+N