Manfred Spraul <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
