Re: Multithreaded SIGPIPE race in libpq on Solaris - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Multithreaded SIGPIPE race in libpq on Solaris
Date
Msg-id CADLWmXUdijRLzV0-aD7L3ndQw1u3a5xKT025nJ+R7Tqva5+66w@mail.gmail.com
Whole thread Raw
In response to Re: Multithreaded SIGPIPE race in libpq on Solaris  (Thomas Munro <munro@ip9.org>)
List pgsql-hackers
On 29 August 2014 01:04, Thomas Munro <munro@ip9.org> wrote:
> 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 discovered that the machine we saw the problem on was running
Solaris 9 at the time, but has been upgraded since.  So I think my
sigwait race theory may have been correct, but we can just put this
down to a historical quirk and forget about it, because Solaris 9 is
basically deceased ("extended support" ends in October 2014).  Sorry
for the noise.

Best regards,
Thomas Munro



pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Per table autovacuum vacuum cost limit behaviour strange
Next
From: arhipov
Date:
Subject: Re: Why data of timestamptz does not store value of timezone passed to it?