Bruce Momjian wrote:
> OK, I like your idea of chaining on to any existing SIGPIPE handler
> rather than just do it if none is installed. I also see your fix for
> the uninitialized thread-specific variable.
>
> I added some comments to the patch, renamed the pipeheader variable so
> it was pg_* to avoid namespace conflicts, and updated the documentation.
>
> Patch attached and applied.
At a glance, this looks like it will break applications that pass
SA_SIGINFO in sa_flags for their SIGPIPE handlers. This changes the
expected signal handler signature to a three-arg form; the extra two
args provide context about where the signal occurred. The libpq handler,
however, doesn't pass those args when chaining to the next handler.
The Sun JVM under linux is one example of an app that does1 this. I've
seen a similar problem to this before with a version of libnss_ldap that
did not correctly restore the entire sigaction state when restoring the
SIGPIPE handler before returning from libnss_ldap .. the next SIGPIPE
that arrives would crash the JVM. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4630104 for more
details (requires registration)
-O