On Sunday, Nov 2, 2003, at 18:16 Europe/Berlin, Tom Lane wrote:
> Manfred Spraul <manfred@colorfullife.com> writes:
>> Tom Lane wrote:
>>> I don't see that this proposal adds any security.
>>>
>> It's not about security:
>
> The proposal would be more salable if it addressed the security problem
> too. As is, you are proposing putting a large wart on libpq's API in
> order to work around an inefficiency that's only been shown to exist in
> one version of one operating system. I'd like to look for other
> solutions before we do that.
>
> One possibility that comes to mind is simply to test whether the
> SIGPIPE
> handler is already SIG_IGN before we munge it. Ideally we'd do that
> once when the conn object is created, but even if it had to be done
> more
> often, it might still be a net win.
That wouldn't offer a solution for people who use SIGPIPE for other
things during the lifetime of the program (after creating the
connection) and if a SIGPIPE handler is called due to the connection,
the handler won't be expecting the source, and polling signal for state
is essentially what you do now. Instead, I propose a
PQsigpipeOK/PQacceptsigpipe/PQrecvsigpipe(PGconn*) or something to that
effect which skips this check for the connection. That way, programmers
are aware that the connection could call their SIGPIPE handler because
they explicitly request it and the library remains backwards-compatible.
