On 28 August 2014 23:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't claim to be an expert on this stuff, but I had the idea that
> multithreaded environments were supposed to track signal state per-thread
> not just per-process, precisely because of issues like this.
After some googling, I found reply #3 in
https://community.oracle.com/thread/1950900?start=0&tstart=0 and
various other sources which say that in Solaris versions 10 they
changed SIGPIPE delivery from per process (as specified by UNIX98) to
per thread (as specified by POSIX:2001). But we are on version 11, so
my theory doesn't look great. (Though 9 is probably still in use out
there somewhere...)
I also found this article:
http://krokisplace.blogspot.co.uk/2010/02/suppressing-sigpipe-in-library.html
The author recommends an approach nearly identical to the PostgreSQL
approach, except s/he says: "to do this we use sigtimedwait() with
zero timeout; this is to avoid blocking in a scenario where malicious
user sent SIGPIPE manually to a whole process: in this case we will
see it pending, but other thread may handle it before we had a
[chance] to wait for it".
Maybe we have malicious users sending signals to processes. It does
seem more likely the crashing database triggered this somehow though,
perhaps in combination with something else the client app was doing,
though I can't think what it could be that would eat another thread's
SIGPIPE in between the sigpending and sigwait syscalls.
Best regards,
Thomas Munro
