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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to